Closed magiruuvelvet closed 1 year ago
Interesting ticket upstream: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3316
Not sure if this problem is related to this issue, since only ALSA devices are mentioned there (Bluetooth audio devices are listed as BlueZ, not ALSA, in PipeWire), but keep an eye on that one.
New discovery: The Bluetooth audio playback only becomes unstable when you mix streams of different sample rates and the resampler kicks in. Which means if you have a music library with different sample rates (Hi-Res, Standard Res, etc.) you will most likely experience audio cut-outs and crashes in PipeWire during Bluetooth playback.
PipeWire on Bluetooth didn't crash a single time on me when there was a consistent sample rate during my testing.
Fixed in 0.3.74
. In the meantime, apply this patchset to get the fixes early.
Bluetooth audio is utterly broken with PipeWire when multiple streams are active or if streams are rapidly opened/closed, no issues with PulseAudio. USB Audio (FiiO M5) works perfectly fine and can handle the heat and never breaks when spamming streams or having multiple concurrent streams open.
Investigation is ongoing. Experimenting with different quantum values and sample rates didn't lead to any meaningful results yet. My only guess is that the Bluetooth plugin in PipeWire does some weird buffering.
Kernel version:
5.15.119-gentoo-dist
For reference: Bluetooth audio on PulseAudio works perfectly fine on my system. Spamming streams was never an issue there. Why does this matter? Applications which play notification sounds, or simply just having sneaky audio playback in web browsers while listening to music, breaks the playback on PipeWire and I need to restart it in the worst case, sometimes switching profiles fixes it. This is far from being useable in production right now.
Debugging: You can install PulseAudio and PipeWire at the same time by using my media-sound/pulseaudio-daemon-noconflict ebuild. Only system mode is supported.