Re: [pulseaudio-discuss] RAOP2 patch testing result
19.01.2015 10:24, Arun Raghavan wrote: On 19 January 2015 at 10:31, Alexander E. Patrakov patra...@gmail.com wrote: 19.01.2015 05:33, Hajime Fujita wrote: [...] Also, here's how I launched valgrind. If more detailed options are necessary please let me know. $ valgrind --leak-check=yes ./src/.libs/pulseaudio ... Well, that differs from the way I tried that: valgrind --trace-children=yes ./src/pulseaudio The difference is because our intentions were different: you were focusing on finding memory leaks, while I was searching for uninitialized variables and use-after-free errors. And, I was trying to make sure that the just-compiled libraries are used, and the libtool-generated bash wrapper knows best how to do that. Of course, we can combine our flags, and replace --leak-check=yes with --leak-check=full. You could also use this to make sure the libs are picked up from the build directory: libtool --mode=execute valgrind --leak-check=full --trace-children=yes ./src/pulseaudio Thanks for the tip. Anyway, here is what I get with the portable version of libressl (installed into a separate prefix in order to avoid conflicts with the system-installed openssl, and added to PKG_CONFIG_PATH). On connection: ==6892== Use of uninitialised value of size 8 ==6892==at 0x223831FA: pa_raop_base64_encode (raop-util.c:117) ==6892==by 0x223857A7: rtsp_auth_cb (raop-client.c:1208) ==6892==by 0x22178E57: on_connection (rtsp_client.c:342) ==6892==by 0x5D75DC5: do_call (socket-client.c:161) ==6892==by 0x50EF183: dispatch_pollfds (mainloop.c:657) ==6892==by 0x50EF183: pa_mainloop_dispatch (mainloop.c:900) ==6892==by 0x50EF559: pa_mainloop_iterate (mainloop.c:931) ==6892==by 0x50EF5FF: pa_mainloop_run (mainloop.c:946) ==6892==by 0x406DE5: main (main.c:1136) ==6892== ==6892== Use of uninitialised value of size 8 ==6892==at 0x22383201: pa_raop_base64_encode (raop-util.c:118) ==6892==by 0x223857A7: rtsp_auth_cb (raop-client.c:1208) ==6892==by 0x22178E57: on_connection (rtsp_client.c:342) ==6892==by 0x5D75DC5: do_call (socket-client.c:161) ==6892==by 0x50EF183: dispatch_pollfds (mainloop.c:657) ==6892==by 0x50EF183: pa_mainloop_dispatch (mainloop.c:900) ==6892==by 0x50EF559: pa_mainloop_iterate (mainloop.c:931) ==6892==by 0x50EF5FF: pa_mainloop_run (mainloop.c:946) ==6892==by 0x406DE5: main (main.c:1136) ==6892== ==6892== Use of uninitialised value of size 8 ==6892==at 0x22383215: pa_raop_base64_encode (raop-util.c:120) ==6892==by 0x223857A7: rtsp_auth_cb (raop-client.c:1208) ==6892==by 0x22178E57: on_connection (rtsp_client.c:342) ==6892==by 0x5D75DC5: do_call (socket-client.c:161) ==6892==by 0x50EF183: dispatch_pollfds (mainloop.c:657) ==6892==by 0x50EF183: pa_mainloop_dispatch (mainloop.c:900) ==6892==by 0x50EF559: pa_mainloop_iterate (mainloop.c:931) ==6892==by 0x50EF5FF: pa_mainloop_run (mainloop.c:946) ==6892==by 0x406DE5: main (main.c:1136) ==6892== ==6892== Use of uninitialised value of size 8 ==6892==at 0x2238321C: pa_raop_base64_encode (raop-util.c:119) ==6892==by 0x223857A7: rtsp_auth_cb (raop-client.c:1208) ==6892==by 0x22178E57: on_connection (rtsp_client.c:342) ==6892==by 0x5D75DC5: do_call (socket-client.c:161) ==6892==by 0x50EF183: dispatch_pollfds (mainloop.c:657) ==6892==by 0x50EF183: pa_mainloop_dispatch (mainloop.c:900) ==6892==by 0x50EF559: pa_mainloop_iterate (mainloop.c:931) ==6892==by 0x50EF5FF: pa_mainloop_run (mainloop.c:946) ==6892==by 0x406DE5: main (main.c:1136) ==6892== ==6892== Invalid write of size 1 ==6892==at 0x22179316: line_callback (rtsp_client.c:241) ==6892==by 0x5D60D26: scan_for_lines (ioline.c:271) ==6892==by 0x5D60D26: do_read (ioline.c:339) ==6892==by 0x5D60D26: do_work (ioline.c:388) ==6892==by 0x50EF183: dispatch_pollfds (mainloop.c:657) ==6892==by 0x50EF183: pa_mainloop_dispatch (mainloop.c:900) ==6892==by 0x50EF559: pa_mainloop_iterate (mainloop.c:931) ==6892==by 0x50EF5FF: pa_mainloop_run (mainloop.c:946) ==6892==by 0x406DE5: main (main.c:1136) ==6892== Address 0x1baa09f8 is 72 bytes inside a block of size 152 free'd ==6892==at 0x4C2A1AC: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==6892==by 0x51039BE: pa_xfree (xmalloc.c:131) ==6892==by 0x2238571B: rtsp_auth_cb (raop-client.c:1305) ==6892==by 0x22179315: headers_read (rtsp_client.c:171) ==6892==by 0x22179315: line_callback (rtsp_client.c:240) ==6892==by 0x5D60D26: scan_for_lines (ioline.c:271) ==6892==by 0x5D60D26: do_read (ioline.c:339) ==6892==by 0x5D60D26: do_work (ioline.c:388) ==6892==by 0x50EF183: dispatch_pollfds (mainloop.c:657) ==6892==by 0x50EF183: pa_mainloop_dispatch (mainloop.c:900) ==6892==by 0x50EF559: pa_mainloop_iterate (mainloop.c:931) ==6892==by 0x50EF5FF: pa_mainloop_run (mainloop.c:946) ==6892==by 0x406DE5: main (main.c:1136) ==6892== On
Re: [pulseaudio-discuss] RAOP2 patch testing result
On 19 January 2015 at 10:31, Alexander E. Patrakov patra...@gmail.com wrote: 19.01.2015 05:33, Hajime Fujita wrote: [...] Also, here's how I launched valgrind. If more detailed options are necessary please let me know. $ valgrind --leak-check=yes ./src/.libs/pulseaudio ... Well, that differs from the way I tried that: valgrind --trace-children=yes ./src/pulseaudio The difference is because our intentions were different: you were focusing on finding memory leaks, while I was searching for uninitialized variables and use-after-free errors. And, I was trying to make sure that the just-compiled libraries are used, and the libtool-generated bash wrapper knows best how to do that. Of course, we can combine our flags, and replace --leak-check=yes with --leak-check=full. You could also use this to make sure the libs are picked up from the build directory: libtool --mode=execute valgrind --leak-check=full --trace-children=yes ./src/pulseaudio -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] RAOP2 patch testing result
19.01.2015 05:33, Hajime Fujita wrote: Hello Alexander, I think I have fixed the leaks, and pushed the changes to https://github.com/hfujita/pulseaudio-raop2 (at `hf/raop2-v2-v5.99.2` branch -- now it's rebased against RC2). Could you give it a try? Just did that. You fixed memory leaks, but not uninitialized/freed memory accesses. Here is what I get when loading module-raop-discover (using pactl load-module) while HiFi Speaker is running on my phone: ==6761== Use of uninitialised value of size 8 ==6761==at 0x223831FA: pa_raop_base64_encode (raop-util.c:117) ==6761==by 0x223857A7: rtsp_auth_cb (raop-client.c:1208) ==6761==by 0x22178E47: on_connection (rtsp_client.c:342) ==6761==by 0x5D75DB5: do_call (socket-client.c:161) ==6761==by 0x50EF173: dispatch_pollfds (mainloop.c:657) ==6761==by 0x50EF173: pa_mainloop_dispatch (mainloop.c:900) ==6761==by 0x50EF549: pa_mainloop_iterate (mainloop.c:931) ==6761==by 0x50EF5EF: pa_mainloop_run (mainloop.c:946) ==6761==by 0x406DD5: main (main.c:1136) ==6761== ==6761== Use of uninitialised value of size 8 ==6761==at 0x22383201: pa_raop_base64_encode (raop-util.c:118) ==6761==by 0x223857A7: rtsp_auth_cb (raop-client.c:1208) ==6761==by 0x22178E47: on_connection (rtsp_client.c:342) ==6761==by 0x5D75DB5: do_call (socket-client.c:161) ==6761==by 0x50EF173: dispatch_pollfds (mainloop.c:657) ==6761==by 0x50EF173: pa_mainloop_dispatch (mainloop.c:900) ==6761==by 0x50EF549: pa_mainloop_iterate (mainloop.c:931) ==6761==by 0x50EF5EF: pa_mainloop_run (mainloop.c:946) ==6761==by 0x406DD5: main (main.c:1136) ==6761== ==6761== Use of uninitialised value of size 8 ==6761==at 0x22383215: pa_raop_base64_encode (raop-util.c:120) ==6761==by 0x223857A7: rtsp_auth_cb (raop-client.c:1208) ==6761==by 0x22178E47: on_connection (rtsp_client.c:342) ==6761==by 0x5D75DB5: do_call (socket-client.c:161) ==6761==by 0x50EF173: dispatch_pollfds (mainloop.c:657) ==6761==by 0x50EF173: pa_mainloop_dispatch (mainloop.c:900) ==6761==by 0x50EF549: pa_mainloop_iterate (mainloop.c:931) ==6761==by 0x50EF5EF: pa_mainloop_run (mainloop.c:946) ==6761==by 0x406DD5: main (main.c:1136) ==6761== ==6761== Use of uninitialised value of size 8 ==6761==at 0x2238321C: pa_raop_base64_encode (raop-util.c:119) ==6761==by 0x223857A7: rtsp_auth_cb (raop-client.c:1208) ==6761==by 0x22178E47: on_connection (rtsp_client.c:342) ==6761==by 0x5D75DB5: do_call (socket-client.c:161) ==6761==by 0x50EF173: dispatch_pollfds (mainloop.c:657) ==6761==by 0x50EF173: pa_mainloop_dispatch (mainloop.c:900) ==6761==by 0x50EF549: pa_mainloop_iterate (mainloop.c:931) ==6761==by 0x50EF5EF: pa_mainloop_run (mainloop.c:946) ==6761==by 0x406DD5: main (main.c:1136) ==6761== ==6761== Invalid write of size 1 ==6761==at 0x22179306: line_callback (rtsp_client.c:241) ==6761==by 0x5D60D16: scan_for_lines (ioline.c:271) ==6761==by 0x5D60D16: do_read (ioline.c:339) ==6761==by 0x5D60D16: do_work (ioline.c:388) ==6761==by 0x50EF173: dispatch_pollfds (mainloop.c:657) ==6761==by 0x50EF173: pa_mainloop_dispatch (mainloop.c:900) ==6761==by 0x50EF549: pa_mainloop_iterate (mainloop.c:931) ==6761==by 0x50EF5EF: pa_mainloop_run (mainloop.c:946) ==6761==by 0x406DD5: main (main.c:1136) ==6761== Address 0x1ba75ee8 is 72 bytes inside a block of size 152 free'd ==6761==at 0x4C2A1AC: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==6761==by 0x51039AE: pa_xfree (xmalloc.c:131) ==6761==by 0x2238571B: rtsp_auth_cb (raop-client.c:1305) ==6761==by 0x22179305: headers_read (rtsp_client.c:171) ==6761==by 0x22179305: line_callback (rtsp_client.c:240) ==6761==by 0x5D60D16: scan_for_lines (ioline.c:271) ==6761==by 0x5D60D16: do_read (ioline.c:339) ==6761==by 0x5D60D16: do_work (ioline.c:388) ==6761==by 0x50EF173: dispatch_pollfds (mainloop.c:657) ==6761==by 0x50EF173: pa_mainloop_dispatch (mainloop.c:900) ==6761==by 0x50EF549: pa_mainloop_iterate (mainloop.c:931) ==6761==by 0x50EF5EF: pa_mainloop_run (mainloop.c:946) ==6761==by 0x406DD5: main (main.c:1136) ==6761== Here is the additional output when I play music with mpv to the sink. But note that some (but not all!) of that may be due to OpenSSL misfeatures, it may be a good idea to retest with LibreSSL, and I will do that later. ==6761== Conditional jump or move depends on uninitialised value(s) ==6761==at 0x22894F39: BN_bin2bn (in /usr/lib64/libcrypto.so.1.0.0) ==6761==by 0x228B5599: ??? (in /usr/lib64/libcrypto.so.1.0.0) ==6761==by 0x22383A93: rsa_encrypt (raop-crypto.c:76) ==6761==by 0x22383A93: pa_raop_secret_get_key (raop-crypto.c:118) ==6761==by 0x2238503C: rtsp_stream_cb (raop-client.c:901) ==6761==by 0x22178E47: on_connection (rtsp_client.c:342) ==6761==by 0x5D75DB5: do_call (socket-client.c:161) ==6761==by 0x50EF173:
Re: [pulseaudio-discuss] RAOP2 patch testing result
Hello Alexander, I think I have fixed the leaks, and pushed the changes to https://github.com/hfujita/pulseaudio-raop2 (at `hf/raop2-v2-v5.99.2` branch -- now it's rebased against RC2). Could you give it a try? Also, here's how I launched valgrind. If more detailed options are necessary please let me know. $ valgrind --leak-check=yes ./src/.libs/pulseaudio ... Detailed output from valgrind can be found here: https://github.com/hfujita/pulseaudio-raop2/issues/35 Thank you, Hajime Alexander E. Patrakov wrote: 05.01.2015 08:57, Hajime Fujita wrote: Hello Alexander, Then I pressed the back arrow to seek back. Result: it froze. Also tested with VLC, seeking there does not freeze. We believe we finally figured out the cause and fixed the issue. Please try the latest patches in https://github.com/hfujita/pulseaudio-raop2 (at `hf/raop2-v2-v5.99.1` branch). Fixed indeed. The detailed discussion can be found here: https://github.com/hfujita/pulseaudio-raop2/issues/31 With Bino, I was able to trigger this assertion failure: E: [raop-sink-[192.168.1.39]:5000] rtsp_client.c: Assertion 'c-url' failed at modules/rtp/rtsp_client.c:441, function rtsp_exec(). Aborting. I could not reproduce this (Bino immediately crashed with any of my input file), but I believe this has also been fixed in the above branch. (https://github.com/hfujita/pulseaudio-raop2/issues/9) Indeed, there is no such crash anymore. Then I started Airfoil Speakers on Android. Result: PulseAudio does not see it, even if module-raop-discover is reloaded. And Airfoil Speakers is not a RAOP2 server. So not a bug. Still, we have a lot of valgrind splats during normal usage of the module, please find them in the attached file. If your PC is not fast enough by default to valgrind pulseaudio (i.e. if pulseaudio gets killed on starting a new stream due to exhausting the realtime budget), this default.pa tweak can help: load-module module-udev-detect tsched_buffer_size=5 ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] RAOP2 patch testing result
Hello Alexander, Alexander E. Patrakov wrote: 13.11.2014 02:13, Martin Blanchard wrote: On Tue, 2014-11-11 at 23:45 +0500, Alexander E. Patrakov wrote: Hi. Hello Alexander! I have cloned the raop2-v2 branch from https://github.com/colinleroy/pulseaudio First, thanks for the testings. The following test was applied. I have installed the Android HiFi application (also known as HiFi Speaker), version 1.7 Beta, on my Android phone, and started it. Link: http://forum.xda-developers.com/showthread.php?p=29986442 Version is important: this one is possibly-buggy in an interesting way. Also, newer versions require a license for more than 30 minutes of playback. Note: for some reason, Google Play has removed this app, so you can only get it from various shady sources such as above. Then, I ran the following command: pacmd load-module module-raop-discover Result: it found the speaker! Then I started mpv on a music file, and redirected its output to the HiFi Speaker using pavucontrol. Result: it worked. Then I pressed the back arrow to seek back. Result: it froze. I can reproduce that, will try to fix it. You should not experience such a problem with GStreamer based players, I think. Have you try any other players? I had no GStreamer-based players installed, so installed gst123 for a quick test. Result: same freeze. Also tested with VLC, seeking there does not freeze. We believe we finally figured out the cause and fixed the issue. Please try the latest patches in https://github.com/hfujita/pulseaudio-raop2 (at `hf/raop2-v2-v5.99.1` branch). The detailed discussion can be found here: https://github.com/hfujita/pulseaudio-raop2/issues/31 With Bino, I was able to trigger this assertion failure: E: [raop-sink-[192.168.1.39]:5000] rtsp_client.c: Assertion 'c-url' failed at modules/rtp/rtsp_client.c:441, function rtsp_exec(). Aborting. I could not reproduce this (Bino immediately crashed with any of my input file), but I believe this has also been fixed in the above branch. (https://github.com/hfujita/pulseaudio-raop2/issues/9) Then I killed the HiFi Speaker application on Android. Result: PulseAudio unfroze mpv's stream and moved it back to analog headphones. Then I started Airfoil Speakers on Android. Result: PulseAudio does not see it, even if module-raop-discover is reloaded. This may be a module-raop-discover bug (Avahi related). Can you post the full pulseaudio log? Sure. And here is what avahi-browse --all prints: aep@aep-haswell ~/raop/pulseaudio $ avahi-browse --all + eno1 IPv6 aep@aep-haswell: Built-in Audio Digital Stereo (HDMI) _pulse-sink._tcp local + eno1 IPv6 aep@aep-haswell: Built-in Audio Analog Stereo _pulse-sink._tcp local + eno1 IPv4 aep@aep-haswell: Built-in Audio Digital Stereo (HDMI) _pulse-sink._tcp local + eno1 IPv4 aep@aep-haswell: Built-in Audio Analog Stereo _pulse-sink._tcp local + eno1 IPv6 aep@aep-haswell _pulse-server._tcp local + eno1 IPv4 aep@aep-haswell _pulse-server._tcp local + eno1 IPv6 aep@aep-haswell: HD Webcam C910 Analog Stereo _pulse-source._tcp local + eno1 IPv6 aep@aep-haswell: Built-in Audio Analog Stereo _pulse-source._tcp local + eno1 IPv4 aep@aep-haswell: HD Webcam C910 Analog Stereo _pulse-source._tcp local + eno1 IPv4 aep@aep-haswell: Built-in Audio Analog Stereo _pulse-source._tcp local + eno1 IPv6 aep-haswell _ssh._tcp local + eno1 IPv4 aep-haswell _ssh._tcp local + eno1 IPv6 aep-haswell [94:de:80:6f:9a:d4] _workstation._tcplocal + eno1 IPv4 aep-haswell [94:de:80:6f:9a:d4] _workstation._tcplocal + eno1 IPv6 aep-haswell _sftp-ssh._tcp local + eno1 IPv4 aep-haswell _sftp-ssh._tcp local + eno1 IPv6 5CF8A18FB95B@Android _airfoilspeaker._tcp local + eno1 IPv6 5CF8A18FB95B@Android (2) _airfoilspeaker._tcp local + eno1 IPv4 5CF8A18FB95B@Android _airfoilspeaker._tcp local - eno1 IPv4 5CF8A18FB95B@Android _airfoilspeaker._tcp local - eno1 IPv6 5CF8A18FB95B@Android _airfoilspeaker._tcp local + eno1 IPv4 5CF8A18FB95B@Android _airfoilspeaker._tcp local + eno1 IPv6 5CF8A18FB95B@Android _airfoilspeaker._tcp local The relevant part of the pulseaudio log is: D: [raop-sink-[192.168.1.39]:5000] raop-client.c: Can't stream, connection not established yet... D: [raop-sink-[192.168.1.39]:5000] raop-client.c: Can't stream, connection not established yet... D: [raop-sink-[192.168.1.39]:5000] raop-client.c: Can't stream, connection not established yet... D: [raop-sink-[192.168.1.39]:5000] raop-client.c: Can't stream, connection not established yet... D: [pulseaudio] socket-client.c: connect(): Connection refused E: [pulseaudio] rtsp_client.c: Connection failed: Connection refused So - it is not on port 5000. This connects and pretends to send audio: pacmd load-module module-raop-sink 'server=[192.168.1.39]:6000' sink_name=raop_output.Airfoil.local
Re: [pulseaudio-discuss] RAOP2 patch testing result
13.11.2014 02:13, Martin Blanchard wrote: On Tue, 2014-11-11 at 23:45 +0500, Alexander E. Patrakov wrote: Hi. Hello Alexander! I have cloned the raop2-v2 branch from https://github.com/colinleroy/pulseaudio First, thanks for the testings. The following test was applied. I have installed the Android HiFi application (also known as HiFi Speaker), version 1.7 Beta, on my Android phone, and started it. Link: http://forum.xda-developers.com/showthread.php?p=29986442 Version is important: this one is possibly-buggy in an interesting way. Also, newer versions require a license for more than 30 minutes of playback. Note: for some reason, Google Play has removed this app, so you can only get it from various shady sources such as above. Then, I ran the following command: pacmd load-module module-raop-discover Result: it found the speaker! Then I started mpv on a music file, and redirected its output to the HiFi Speaker using pavucontrol. Result: it worked. Then I pressed the back arrow to seek back. Result: it froze. I can reproduce that, will try to fix it. You should not experience such a problem with GStreamer based players, I think. Have you try any other players? I had no GStreamer-based players installed, so installed gst123 for a quick test. Result: same freeze. Also tested with VLC, seeking there does not freeze. With Bino, I was able to trigger this assertion failure: E: [raop-sink-[192.168.1.39]:5000] rtsp_client.c: Assertion 'c-url' failed at modules/rtp/rtsp_client.c:441, function rtsp_exec(). Aborting. Then I killed the HiFi Speaker application on Android. Result: PulseAudio unfroze mpv's stream and moved it back to analog headphones. Then I started Airfoil Speakers on Android. Result: PulseAudio does not see it, even if module-raop-discover is reloaded. This may be a module-raop-discover bug (Avahi related). Can you post the full pulseaudio log? Sure. And here is what avahi-browse --all prints: aep@aep-haswell ~/raop/pulseaudio $ avahi-browse --all + eno1 IPv6 aep@aep-haswell: Built-in Audio Digital Stereo (HDMI) _pulse-sink._tcp local + eno1 IPv6 aep@aep-haswell: Built-in Audio Analog Stereo _pulse-sink._tcp local + eno1 IPv4 aep@aep-haswell: Built-in Audio Digital Stereo (HDMI) _pulse-sink._tcp local + eno1 IPv4 aep@aep-haswell: Built-in Audio Analog Stereo _pulse-sink._tcp local + eno1 IPv6 aep@aep-haswell _pulse-server._tcp local + eno1 IPv4 aep@aep-haswell _pulse-server._tcp local + eno1 IPv6 aep@aep-haswell: HD Webcam C910 Analog Stereo _pulse-source._tcp local + eno1 IPv6 aep@aep-haswell: Built-in Audio Analog Stereo _pulse-source._tcp local + eno1 IPv4 aep@aep-haswell: HD Webcam C910 Analog Stereo _pulse-source._tcp local + eno1 IPv4 aep@aep-haswell: Built-in Audio Analog Stereo _pulse-source._tcp local + eno1 IPv6 aep-haswell _ssh._tcp local + eno1 IPv4 aep-haswell _ssh._tcp local + eno1 IPv6 aep-haswell [94:de:80:6f:9a:d4] _workstation._tcplocal + eno1 IPv4 aep-haswell [94:de:80:6f:9a:d4] _workstation._tcplocal + eno1 IPv6 aep-haswell _sftp-ssh._tcp local + eno1 IPv4 aep-haswell _sftp-ssh._tcp local + eno1 IPv6 5CF8A18FB95B@Android _airfoilspeaker._tcp local + eno1 IPv6 5CF8A18FB95B@Android (2) _airfoilspeaker._tcp local + eno1 IPv4 5CF8A18FB95B@Android _airfoilspeaker._tcp local - eno1 IPv4 5CF8A18FB95B@Android _airfoilspeaker._tcp local - eno1 IPv6 5CF8A18FB95B@Android _airfoilspeaker._tcp local + eno1 IPv4 5CF8A18FB95B@Android _airfoilspeaker._tcp local + eno1 IPv6 5CF8A18FB95B@Android _airfoilspeaker._tcp local The relevant part of the pulseaudio log is: D: [raop-sink-[192.168.1.39]:5000] raop-client.c: Can't stream, connection not established yet... D: [raop-sink-[192.168.1.39]:5000] raop-client.c: Can't stream, connection not established yet... D: [raop-sink-[192.168.1.39]:5000] raop-client.c: Can't stream, connection not established yet... D: [raop-sink-[192.168.1.39]:5000] raop-client.c: Can't stream, connection not established yet... D: [pulseaudio] socket-client.c: connect(): Connection refused E: [pulseaudio] rtsp_client.c: Connection failed: Connection refused So - it is not on port 5000. This connects and pretends to send audio: pacmd load-module module-raop-sink 'server=[192.168.1.39]:6000' sink_name=raop_output.Airfoil.local sink_properties='device.description=Airfoil-Speakers' protocol=UDP encryption=RSA codec=ALAC channels=2 format=16 rate=44100 protocol=TCP causes Airfoil Speakers to crash. All the attempts of PulseAudio to speak to Airfoil Speakers have been logged and attached. -- Alexander E. Patrakov pulse-raop.log.gz Description: application/gzip ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org
Re: [pulseaudio-discuss] RAOP2 patch testing result
On Tue, 2014-11-11 at 23:45 +0500, Alexander E. Patrakov wrote: Hi. Hello Alexander! I have cloned the raop2-v2 branch from https://github.com/colinleroy/pulseaudio First, thanks for the testings. The following test was applied. I have installed the Android HiFi application (also known as HiFi Speaker), version 1.7 Beta, on my Android phone, and started it. Link: http://forum.xda-developers.com/showthread.php?p=29986442 Version is important: this one is possibly-buggy in an interesting way. Also, newer versions require a license for more than 30 minutes of playback. Note: for some reason, Google Play has removed this app, so you can only get it from various shady sources such as above. Then, I ran the following command: pacmd load-module module-raop-discover Result: it found the speaker! Then I started mpv on a music file, and redirected its output to the HiFi Speaker using pavucontrol. Result: it worked. Then I pressed the back arrow to seek back. Result: it froze. I can reproduce that, will try to fix it. You should not experience such a problem with GStreamer based players, I think. Have you try any other players? Then I killed the HiFi Speaker application on Android. Result: PulseAudio unfroze mpv's stream and moved it back to analog headphones. Then I started Airfoil Speakers on Android. Result: PulseAudio does not see it, even if module-raop-discover is reloaded. This may be a module-raop-discover bug (Avahi related). Can you post the full pulseaudio log? I suspected that I could load module-raop-sink manually: pacmd load-module module-raop-sink server=192.168.1.39 protocol=UDP Result: freeze. So it looks like Airfoil Speakers are just incompatible. Well, specifying protocol only may not be enough. You may want to try something like this: pactl load-module module-raop-sink server=[192.168.1.39]:5000 sink_name=raop_output.Airfoil.local sink_properties='device.description=Airfoil-Speakers' protocol=UDP encryption=RSA codec=ALAC channels=2 format=16 rate=44100 Started HiFi Speaker again, now it got autodetected. So the module should have some more graceful detection of dead or buggy receivers. Agreed, but the issues you are reporting here are likely to be bugs or problems in our RAOP client implementation... signature.asc Description: This is a digitally signed message part ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] RAOP2 patch testing result
Hi. I have cloned the raop2-v2 branch from https://github.com/colinleroy/pulseaudio The following test was applied. I have installed the Android HiFi application (also known as HiFi Speaker), version 1.7 Beta, on my Android phone, and started it. Link: http://forum.xda-developers.com/showthread.php?p=29986442 Version is important: this one is possibly-buggy in an interesting way. Also, newer versions require a license for more than 30 minutes of playback. Note: for some reason, Google Play has removed this app, so you can only get it from various shady sources such as above. Then, I ran the following command: pacmd load-module module-raop-discover Result: it found the speaker! Then I started mpv on a music file, and redirected its output to the HiFi Speaker using pavucontrol. Result: it worked. Then I pressed the back arrow to seek back. Result: it froze. Then I killed the HiFi Speaker application on Android. Result: PulseAudio unfroze mpv's stream and moved it back to analog headphones. Then I started Airfoil Speakers on Android. Result: PulseAudio does not see it, even if module-raop-discover is reloaded. I suspected that I could load module-raop-sink manually: pacmd load-module module-raop-sink server=192.168.1.39 protocol=UDP Result: freeze. So it looks like Airfoil Speakers are just incompatible. Started HiFi Speaker again, now it got autodetected. So the module should have some more graceful detection of dead or buggy receivers. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
