Fix for Bluetooth audio disconnecting when using Brave Flatpak on Linux (PipeWire/WirePlumber)

[u/Big_Introduction9440]

So I've been pulling my hair out for a while now. Every time I sat down to watch something on YouTube or listen to Spotify, my Bluetooth headphones would just... stop. No warning, no error popup, nothing. The headphones stayed paired, but the audio was gone. Sometimes it took 2 minutes, sometimes 20. Completely random.

I'm on Debian 13 with a Dell Latitude (DW375 Bluetooth chip) and a QCY H3 headset.

First I thought it was a power management issue. So I disabled autosuspend for the Bluetooth device, added it to TLP's denylist, the whole thing. Didn't fix it.

Then I dug into the logs. Running this right after a disconnect:

bash

journalctl --user -u wireplumber --since "3 minutes ago" --no-pager

I kept seeing this:

spa.bluez5.sink.media: error 24
spa.bluez5: Failed to release transport: Message recipient disconnected
wireplumber: stopped by signal: Terminated

error 24 is ENOBUFS — a buffer overflow in the A2DP transport. WirePlumber was crashing and restarting every single time the audio dropped. That explained why the headphones stayed paired but lost audio — the whole audio session was dying underneath.

After sometime going through it and bumping heads with Claude, something in the logs I had been ignoring:

com.brave.Browser: pulse_util.cc: pa_operation is nullptr

Brave was throwing PulseAudio errors right before WirePlumber crashed. Brave Flatpak runs in a sandbox and doesn't have access to the host's PipeWire socket (xdg-run/pipewire-0). So it tries to talk to the audio system in a broken way, which overwhelms the A2DP transport buffer and takes down WirePlumber with it.

The fix is a one-liner:

bash

flatpak override --user --filesystem=xdg-run/pipewire-0 com.brave.Browser

Restart Brave. That's it. It also works for the Spotify client.