Bugzilla – Bug 1223305
[Regression] Bluetooth audio devices reset/disconnected/audio profile changed(??) when wine/proton applications initialize sound
Last modified: 2024-06-18 21:19:43 UTC
I'm sadly having what seems to be a regression possibly related to Plasma 5 to 6. Now often when wine or proton applications initialize audio , e.g. when I startup EA App inside Steam at launch, or something like REAPER's windows version ( https://reaper.fm/ the trial is free and unrestricted) at any time I press "play", the following happens: 1. Audio drops out completely for a split second. 2. A visible notification is shown like my bluetooth device just freshly connected 3. Audio profile is degraded to something horrible, it sounds like the worst quality headset telephony codec. 4. Sometimes a second later it resets back to what bluetooth profile I had before, usually high-quality playback only "AAC". But sometimes it also just doesn't. This can be checked in plasma's audio device panel, where it will show the telephony codec "Headset Unit ... mSBC" profile in case it didn't reset properly. This also happens when another application is already playing audio in parallel, which sadly makes this disruptive.
Could it be a recent update of pipewire, or something else such as kernel? If it were a kernel, you can boot the previous kernel(s) and check whether the problem persists. If it's other packages, there are some old TW packages available in TW history repo http://download.opensuse.org/history/ and you can try downgrade the stuff, too.
Okay, after more investigation I think I figured out what might be going on: It seems something, pipewire, plasma, or wine, are more faithful about the applications. And it seems like a ton of Windows application will open an output AND input device needlessly, even if no record button was pressed. However, for some reason all bluetooth headphones I own from different vendors only will do input/output combined at a really garbage quality codec and only allow the high quality audio when input is entirely disabled. Or at least that's all the options pipewire is giving me, but I don't think that's new or the regression here. Therefore, my best guess is this seems to be a conceptual problem. It might not have a non-annoying fix either. If such requests are just plain ignored, then bluetooth mics just won't work out of the box in most Windows apps. If the requests are honored, any audio playback is basically unusable beyond basic conference conversations because it just sounds atrocious with audible artifacts. If the audio components knew if the mic was actually going to be used that wouldn't be an issue, but I assume there is no real way of finding out. However, I think it still makes more sense to err on the side of the microphone not working since all non-bluetooth mics will still work just fine, bluetooth mics tend to be bad anyway, and breaking most audio playback out of the box seems like it will hit the average user worse. Anyway, not sure where this problem would be best addressed, my vague guess would be either wine or pipewire, but I'm not sure. You'd probably know better than me.
I forgot to specify, the above only seems to apply in regards to the permanent near-unusable codec problem which I would say arguably is the worse issue. It doesn't fix the brief audio reset with device reinitialization whenever any app wine/proton requests audio. But when the wine/proton app doesn't actually request an input device permanently, no idea how that works in practice with the actual API calls, then at least it resets back to the working codec immediately. That's the best I can conclude from my observations.* Anyway, this situation is sadly very disruptive. *Foonote: What I tested is set the "Input channels" in REAPER from '2' to '0' in the audio device settings. That downgrades the issue from permanent reversal to a bad codec every time I tab into REAPER to just the brief annoying but temporary interruption.
The brief non-permanent bluetooth profile breakage is also triggered by opening about:support in Firefox or "Help > Troubleshooting Information" in Thunderbird, both of which I assume enumerate/probe audio devices. So it seems like this is indeed related to some applications probing audio devices, maybe by even briefly opening them, and that possibly automatically changing to a low quality audio profile if it involves a microphone. Which seems like without user confirmation, it probably shouldn't do. Seems like this might be a pipewire issue then?
Antonio, any clue?