PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 16:22 UTC (Wed) by NightMonkey (subscriber, #23051)
In reply to: PipeWire: The Linux audio/video bus by josh
Parent article: PipeWire: The Linux audio/video bus

For my use-case (my home network, HiFiBerry Analogue to Digital converters, Raspberry Pis with USB Digital-to-Analogue converters, and analogue audio playback setups), the network audio slinging capability is actually my favorite part of PulseAudio. :) I do hope that use-case gets even more robust with PipeWire. The way PulseAudio seems to magically keep video and audio in sync when playing video locally but directing the audio over a WiFi network is impressive. (Even SnapCast can't do that, but it wasn't built to handle video/audio synchronization.) Cheers!

PipeWire: The Linux audio/video bus

Posted Mar 4, 2021 14:42 UTC (Thu) by mgedmin (subscriber, #34497) [Link] (2 responses)

Ooh, it works nowadays? I tried PA's network audio support exactly once, 15 years ago, and was disappointed to get short pauses exactly 2 minutes apart.

(Much much later I realized that this was probably NetworkManager asking my WiFi card to scan for available networks periodically, which interrupted the PulseAudio stream sufficiently long to cause sound dropouts.)

PipeWire: The Linux audio/video bus

Posted Mar 5, 2021 8:11 UTC (Fri) by lathiat (subscriber, #18567) [Link]

15 years ago was March 2006. The first PulseAudio release was July 2004. Ubuntu shipped it by default in 2008.

Safe to say it might be worth trying again ;)

PipeWire: The Linux audio/video bus

Posted Mar 13, 2021 13:24 UTC (Sat) by mkbosmans (subscriber, #65556) [Link]

Ah, that brings back some memories!

Yes, I think some of those problems were fixed about 10 years ago, with this commit and some of its parents:
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/co...

But those were of course fixes related to general buffer underrun, network latency and clock drift problems. For a periodically interrupted network connection the only solution would be larger buffers, thus more latency for network playback.