If I'm using my bluetooth headphones on zoom, the audio quality is kinda bad. But if I plug in my USB microphone, it immediately gets significantly better - like going from AM radio to FM radio.
I guess this article explains why!
If this is part of the bluetooth spec, the obvious right answer is for the headphones to present themselves as two devices, one for audio output and a separate one for audio input. That way, if the audio input is active, it won't affect audio output. But it also shouldn't be part of the spec, because it's awful behavior.
So... why? Who thought this made sense?
I wish it would do that... say I'm working and having some music from Youtube in the background. Then I get a Teams call, accept it... and the music plays on, leaving me to frantically search for that damn Chrome tab as I try to explain the person calling that I can't hear them over the music at the moment and to bear with me. I think Teams used to do this on its own, but ever since a macOS update it doesn't (reliably?) work any more - either Teams has some sort of bug, some permission got lost along the way, or macOS is buggy, or Youtube's integration into macOS media control is buggy, I don't know.
> If this is part of the bluetooth spec, the obvious right answer is for the headphones to present themselves as two devices, one for audio output and a separate one for audio input. That way, if the audio input is active, it won't affect audio output. But it also shouldn't be part of the spec, because it's awful behavior.
This doesn't work for protocol reasons. It's either A2DP from source to sink, one way, or SBC in both ways. And no "two device" either, most chipsets can't handle two large-bandwidth transmissions at once - my Samsung phone actually won't let me connect more than my smartwatch and AirPods, and it is not able to dual-play on my AirPods and my JBL box.
Bluetooth is nuts.
> And no "two device" either, most chipsets can't handle two large-bandwidth transmissions at once
If so, get a second chip. Is that supposed to be difficult?
- macOS switches to HFP whenever the bluetooth headset is in use for both input and output. Interestingly, using the bluetooth mic and macbook speaker doesn't activate the HFP,
- bluetooth in general (not just HFP) seems to be designed to work under the constraint of tech from 20 years ago. Small bandwidths, small batteries, and small computational power,
- there are very nice codecs like Opus that are not used even though they've been working for over a decade.
From there I think the main problem is: - macOS should not assume you're in a call just because you're using the mic. There are a few scenarios where that's not the case and you might not care about low latency,
- better existing codecs should be used, but aren't for some reason,
- bluetooth specs should update the constraint they have to work under.