magiruuvelvet / gentoo-portage-config

Gentoo Portage config files (attempt to build a fully working LLVM+musl+Linux desktop)
8 stars 2 forks source link

Bluetooth audio on PipeWire not ready for production yet #1

Closed magiruuvelvet closed 1 year ago

magiruuvelvet commented 1 year ago

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.

wireplumber[112313]: (-49) client too slow! rate:1024/48000 pos:23148544 status:triggered

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.

magiruuvelvet commented 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.

magiruuvelvet commented 1 year ago

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.

magiruuvelvet commented 1 year ago

Possible solution found, trying version 0.3.73 with these patches applied on top.

magiruuvelvet commented 1 year ago

Fixed in 0.3.74. In the meantime, apply this patchset to get the fixes early.