https://bugzilla.suse.com/show_bug.cgi?id=1223305 https://bugzilla.suse.com/show_bug.cgi?id=1223305#c2 ell1e changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(el@horse64.org) | --- Comment #2 from ell1e --- 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. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1223305 https://bugzilla.suse.com/show_bug.cgi?id=1223305#c4 --- Comment #4 from ell1e --- 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? -- You are receiving this mail because: You are on the CC list for the bug.