undefined | Better HN

0 pointsthaumasiotes2y ago0 comments

OK, but why? I don't ever want this "feature". If I start using software that listens to my microphone, it immediately mutes any other audio sources.

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?

0 comments

4 comments · 2 top-level

mschuster912y ago· 2 in thread

> If I start using software that listens to my microphone, it immediately mutes any other audio sources.

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.

thaumasiotesOP2y ago

I say the spec is bad, and you say it can't be better because the spec says so?

> 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?

dgrcode2y ago

From my research to write the post, it looks like: - the HFP standard was developed mainly for taking calls in a car. It seems like taking calls is still the main use case up to the latest version 1.9,

- 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.

theptip2y ago

It’s a good question. I can see why the default behavior is the “user friendly” (but lower quality) option. But it’s confusing that there doesn’t seem to be any pro-quality dual device headsets for those willing to go through the extra hassle of setting them up. BoM can’t be a factor these days?

j / k navigate · click thread line to collapse