Comment # 2 on bug 1223305 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.