Bugzilla – Bug 1218026
PulseAudio not showing bluetooth headsets
Last modified: 2024-03-07 12:07:41 UTC
PulseAudio does not show (thus nor use) bluetooth headsets unless the bluetooth system service gets restarted. After restart, (systemctl restart bluetooth) everything works fine. Might be related to another issue which I have, being that KDE does not turn off bluetooth on startup. Bluetooth, somehow, remains on even though I have set it otherwise.
For BT, pipewire might be working more stably. Any chance to switch to pipewire from PulseAudio?
(In reply to Takashi Iwai from comment #1) > For BT, pipewire might be working more stably. Any chance to switch to > pipewire from PulseAudio? Tried already, it works, but horribly. Audio stutters, jams, glitches etc. in other words, unlistenable.
(In reply to Krystof Jelinek from comment #2) > (In reply to Takashi Iwai from comment #1) > > For BT, pipewire might be working more stably. Any chance to switch to > > pipewire from PulseAudio? > > Tried already, it works, but horribly. Audio stutters, jams, glitches etc. > in other words, unlistenable. Hm, that sounds more interesting. Were you testing only the BT audio, or the problem was seen in other audio streams, too? I don't think we'll debug PulseAudio issue here further, and at best report it to the upstream bug tracker. Likely some timing issue and/or a lack of event handling in PA side. OTOH, if a more severe problem is seen with pipewire, we'd like to know the cause -- if you continue that way, please open another bug entry.
(In reply to Takashi Iwai from comment #3) > (In reply to Krystof Jelinek from comment #2) > > (In reply to Takashi Iwai from comment #1) > > > For BT, pipewire might be working more stably. Any chance to switch to > > > pipewire from PulseAudio? > > > > Tried already, it works, but horribly. Audio stutters, jams, glitches etc. > > in other words, unlistenable. > > Hm, that sounds more interesting. Were you testing only the BT audio, or > the problem was seen in other audio streams, too? > > I don't think we'll debug PulseAudio issue here further, and at best report > it to the upstream bug tracker. Likely some timing issue and/or a lack of > event handling in PA side. > > OTOH, if a more severe problem is seen with pipewire, we'd like to know the > cause -- if you continue that way, please open another bug entry. I tried multiple applications, codecs and 2 completely different headsets to no avail, on my mobile phone, both work fine. The severity of the problem is... well, hard to say. PulseAudio does not show the device initially, but after restarting the bluetooth service, it does. PipeWire shows the device without any issues, but the playback is terrible, maybe related to some timing errors as you mentioned, because the stream is all well and then it stops for a second or two, and afterwards plays incredibly fast. Then a few seconds are ok after which the process repeats.
Ah, no, I meant about the timing issue as a cause of PulseAudio problem (the lack of device). I asked whether the problem of pipewire is seen only on BT or also on other sinks (e.g. USB headset or onboard audio), because BT and other audio devices are handled pretty differently. The onboard, DP/HDMI and USB-audio are handled via ALSA drivers while BT is handled via bluez stack. If the same problem is seen commonly over all outputs, it's something wrong in a pipewire core code.
(In reply to Takashi Iwai from comment #5) > Ah, no, I meant about the timing issue as a cause of PulseAudio problem (the > lack of device). > > I asked whether the problem of pipewire is seen only on BT or also on other > sinks (e.g. USB headset or onboard audio), because BT and other audio > devices are handled pretty differently. The onboard, DP/HDMI and USB-audio > are handled via ALSA drivers while BT is handled via bluez stack. If the > same problem is seen commonly over all outputs, it's something wrong in a > pipewire core code. Aaah, nope, only BT.
This problem is likely a race of pipewire and pulseaudio; while pulseaudio is running for the audio, pipewire is still active for other purposes, and it may grab the BT audio device at first. The fix is on the way. You can work around the issue by the following: 1) edit /usr/share/wireplumber/bluetooth.lua.d/50-bluez-config.lua and change `bluez_monitor.enabled = true` to false 2) remove (or move away) the file /usr/share/wireplumber/bluetooth.lua.d/90-enable-all.lua You can try to turn off pipewire user service (if you don't use it for the remote desktop or such), instead, too.
And the recent pipewire package has a workaround for the conflict, which should fix this problem. I close the bug entry for now. Feel free to reopen if the problem persists.