Hi everybody,
I’ve been using a bluetooth headset for a long time, with generally good outcomes.
However, there’s a glitch that is becoming more and more frustrating.
Usually the headset is working very well, even for extended intervals of time, e.g. watching lengthy films.
When I use the headset for videoconferencing however, every now and then the headset loses audio.
It does not disconnect, as I can still see it in the list of audio devices, but it simply does not receive audio anymore. It seems to be still sending audio though (the headset has an integrated microphone).
If I switch audio output to my external speakers, I can usually switch back to the headphones, but only after a few minutes: if I switch right back it doesn’t work.
The symptom is unfortunately very erratic: sometimes I can use the headset for the whole duration of the videocall without problems, sometimes I have to swap audio to the external speakers several times during a single call.
This happens mostly only with videoconferencing, but it happens with different browsers and even different videoconferencing platforms. There must be something in videoconferencing that triggers this behavior.
A few months ago, after a system update, the problem went away and it did not resurface for several weeks, so I thought it was a bug somewhere that had been corrected. But then, it came back.
I have looked at several threads here in the forums, but there were no threads with my symptoms and anyway, following the steps suggested in similar threads did not lead to resolution.
What would you suggest to help me debug the problem?
This is an interesting observation. It might be useful to know a bit about the BT headset hardware. Is the headset operating as a A2DP or HSP/HFP device? Just wondering PipeWire is causing the headset to switch modes while videoconferencing is active?
Check when first working, and then again when not perhaps… pact list card | grep -i "active"
BTW, I assume that the headset has a microphone, and you use that microphone for videoconferencing? Just trying to get a better handle on this. It should be possible to lock it to a mode that suits if that is what is happening here.
Thank you to both of you @deano_ferrari and @marel .
This computer does not have wifi, but I have lots of other devices nearby which use wifi, and my wifi router itself is a mere 2 meters away.
However, as Dean is saying, I have only problems when using videoconferencing software (i.e. Google Meet, Zoom, etc.)
I will check with the command Dean suggested and report back.
Oh, and to respond to Dean: yes, this is a headset operating as A2DP, with microphone.
It is a JBL Tune 510BT.
Current output of your suggested command (I assume you wanted to write ‘pactl list cards’):
Active Profile: output:hdmi-stereo-extra2
Active Profile: input:mono-fallback
Active Profile: output:analog-stereo+input:analog-stereo
Active Profile: a2dp-sink
Could it be that your computer is switching between the built-in microphone on the laptop and the headset microphone? Have you seen any crashes in the (user) system log? Check with coredumpctl and journalctl.
By default, my Tumbleweed uses the built-in microphone on my laptop. I have to manually (I really need to create a profile for that) switch to my Sony WH-1000XM5. And there is no indication that I am on HSP/HFP for the microphone, which it should show. It remains on A2DP for input. When I force it to HSP/HFP, the plasmoid crashes and restarts but suddenly indicates HSP/HFP.
Hi @aggplanta , my problem is with the headphones, not with the microphone.
When it happens, I cannot hear the audio from my colleagues, but apparently they can still hear me (BTW I’m not sure if it’s because the microphone part of the headset is still working, or if it is because the webcam is picking up the audio, as my webcam has a microphone, too).
I see no crashes and I haven’t been able to catch anything suspect in the journal log or in dmesg. But maybe the problem is that I do not exactly know what to look for.
Yes I did, can I ask what is the reason for asking me this question?
Is there a possibility that there is (more) WiFi traffic at the moment the problem happens?
The difference with conferencing is that there is BT return traffic so the BT use the medium almost double. Furthermore the headset has likely a lower BT output power than your computer BT adapter.
WiFi 2G (channels <=14) shares the band with Bluetooth and interoperability problems are often inescapable if especially if both BT and WLAN are running traffic. If possible move WiFi to 5/6G.
Unfortunately BT has almost no functionality to see if interference is a/the problem, there is no ping and there are no counters.
What @aggplanta and I both seem to be speculating is the possibility that if the device switches to HSP/HFP mode, this may be breaking your headset audio. You also need to confirm which mic is in use when video conferencing, and whether it changes mid-conference.
Yes, that is the command. When headset audio breaks during use, run the command again to see if it has changed reported mode.
BTW, if interference was the issue, it would manifest with the BT connection dropping ie headset disconnecting from BlueZ, and the device would vanish from pactl list sinks / pw-dump. At the very least you’d hear garbled crackling audio. It would also be evident watching the logging with sudo journalctl -f, as bluetoothd would be complaining about disconnections and reconnections.
Thank you once again.
Now I need to wait till I have the next lengthy videocall to try to debug what’s happening. I might also ask a friend to help me, but since this will probably take some time (usually the problems start after at least 20 minutes) I prefer to wait for a real video conference, so as not to waste anybody’s time.
I’ll get back to you as soon as I have something to report (soon hopefully).
It just occurred to me this morning that you also have pw-top and pw-cli for fault isolation. pw-cli info all shows all nodes. Which can be good if you just want to compare everything before and after.
pw-cli info all > pw-cli.info.all.before
pw-cli info all > pw-cli.info.all.after
kompare pw-cli.info.all.before pw-cli.info.all.after
Hi everyone, I think I have found what was causing the problems, and it (probably) doesn’t have anything to do with openSUSE.
My BT headset is a multipoint one, so when I power it on it usually connects to the last two devices it was previously connected to.
This almost always means it connects to my computer and to my phone.
This is very convenient, because if I get a phone call while working at my computer I can answer the call directly without having to take off my headset and pick up the phone.
Normally it works “automagically” meaning a phone call will interrupt audio from the computer, and when I hang up the computer audio will resume.
BUT it seems phone notifications (especially the shortest ones) sometime break audio from the computer and it only returns after minutes, or by a forced BT disconnect/reconnect.
In the last few days I have begun disconnecting from the phone when I start a computer videocall and I have never experienced audio loss since.
I’d like to understand if the fact that the audio doesn’t return to the PC automatically for a long time is a problem in the headset or in openSUSE, but now that I’ve found a workaround I’m not inclined into digging deeper.
A big THANK YOU to all those who offered help!!
Best regards
Cris