Streaming audio from streams provided by module-http-protocol-tcp is often impossible over wifi for reasons having nothing to do with sustained connection speed. Over wired ethernet, $ wget -O - http://server:4714/listen/source/alsa_output.pci-0000_00_07.0.analog-stereo.monitor >/dev/null goes at around 180KiB/s, so that's the speed it needs to go at to sustain the stream. When I do the same thing over wifi, I only get a speed of around 100KiB/s—not fast enough. I tested this same wifi connection using an HTTP stream between the same two hosts and got a sustained speed well in excess of 1.5MiB/s, so the wifi is plenty fast enough. It must be some kind of queueing problem on the pulseaudio server end—probably send buffer overflows. For instance, I can stream reliably with the following command run on the remote client: $ ssh server wget -q -O - http://localhost:4714/listen/source/alsa_output.pci-0000_00_07.0.analog-stereo.monitor |aplay -f s16_be -c 2 -r 44100 I'd like the option of increasing the size of this sending buffer, so that I do the same streaming without having to tunnel through ssh. I don't really care how much of an audio delay this incurs, since synchronisation isn't an issue. Even if it were, I'd be OK with adding a corresponding delay to the local audio output to maintain synchronisation. Something like this: $ pactl load-module module-http-protocol-tcp send-buffer-time=500ms
Better still would be an adjustable send buffer that grows when there are too many overflows.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/64.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.