Hacker News new | past | comments | ask | show | jobs | submit login

This is really a Bluetooth issue. The same happens with any headphones that have a mic on any OS.

When Bluetooth mode is switched from Headphones to Headset (with mic), only much lower quality audio codes are used.

Does anyone know if Bluetooth 6 adds support for higher quality codes for Headset?

It's a big issue, in my opinion.




It was a Bluetooth issue years ago. Now it's only an Apple issue where it can't use a more decent codec. On Linux you can choose the mSBC codec and get decent two-way quality on a modern headset.


>Bluetooth issue

Its a licensing issue. The borderlands between the headset and headphone profiles are rife with licensing land-mines - developers have flipped the table and rage-quit the issue, and this technical debt has been shipped.

(Disclaimer: I make headset/headphone firmware for a major competitor and deal with this issue every single week...)


I just encountered the term "The Ultimate Sadness" reading https://www.computerenhance.com/p/the-case-of-the-missing-in... immediately before this post and I feel like you've found an even worse sadness to deal with on a regular basis.

My sympathies, and I appreciate your willingness to wade through neck deep licensing excrement to produce something that still works.


This honestly sounds like a problem I would expect to be solved by white-labelled AliExpress junk products, whose manufacturers can just ignore the licensing issues entirely, because they’re able to hide their IP violations behind reselling through endless shell companies.

But I guess it isn’t solved by that. Why isn’t it?


You can't hide from the fact that you have to get your chips from somewhere, and those chips have to run some software, and if you are going to just copy others' software, you inherit their technical debt too - unless you invest in fixing their bugs - and what white-label AliExpress junk product provider has the time for that?


Regardless of codecs, don't all Bluetooth headsets switch to mono I/O when the microphone connects? I find that to be a much bigger quality hit than the encoding.


Not on Windows to my knowledge.

Using the same headset on both Windows and Linux leads to a very different experience. Windows works fine. Linux has the issue macOS has mentioned here.


> It was a Bluetooth issue years ago

It still is, mSBC is really not that good, plus all things considered reasons go beyond just the codec, see my nearby comment: https://news.ycombinator.com/item?id=41705258

Switching to "2x half-duplex" on both ends is really the best thing. I hate it that you can't separately select audio input and output in iOS.


The macOS utility Audio MIDI Setup allows you to pick separate devices for this and it also lets you separate the device for system sounds from the device for other sounds.


mSBC is still crappy quality compared to what I get on my smartphone. But still Linux allows me to easily use AAC or APTX codec and a separate mic if I want.

I don't understand why all desktop OS can't have something better while when I pair my Bose headset on my smartphone it seems to be using a better quality codec profile.


mSBC has garbage audio quality.


idk man airpods do switch to an AAC variant called AAC-ELD for bidirectional audio but thats still compressed to hell. better than SBC but not as good as unidirectional AAC.

I had high hopes for BLE Audio but that seems to be stalled


No, I've had this happen multiple times using various bluetooth headphones with my Google Pixel 8. So it's definitely happening on Android as well.


It happens on Windows too. In fact it's probably worst there, because the Windows Bluetooth stack is so awful.


> Now it's only an Apple issue where it can't use a more decent codec.

Isn't this a Mac-specific issue? I have some recollection in my head that Mac OS uses a terrible codec for bidirectional bluetooth audio, but iOS uses a good one.


It’s sometimes still an issue on windows but besides advertising the headset audio device most good headsets will create one or more additional audio devices that support high quality input and output.


Yet another Apple gotcha. I stoped paying the Apple tax long ago. The “ it just works” mantra is long gone


Bluetooth 5.2 was supposed to fix this issue. Indeed, my S22 phone with Jabra Elite 8s sounds great in calls.

MacBooks newer than 2023 SHOULD have better call quality. They have Bluetooth 5.3¹. Can anybody confirm this? I have been meaning to try pairing my earbuds with a floor model at a store and testing audio quality but's only to satisfy a curiosity for me.

---

1. https://support.apple.com/en-us/111838


I've always thought that my 3.5mm corded earbuds, with a mic pill that hangs near my throat, have great mic quality and even better ambient rejection compared to the distant mic buried in the speaker grille of my laptop. Importantly, it's not incredibly disruptive to type notes or use the laptop while in the meeting.

Is this specifically a Bluetooth headphone thing, or an "any headphones with a mic on any OS" thing?


MacOS excels at noise cancellation. Typing on my Windows PC sounds like an earthquake, but you could actually hammer nails during a video call on a Mac and it wouldn't be picked up (it also blocks your voice from coming through, but that’s temporary)


Why is Bluetooth so bad? This, plus the literal second of latency to my car's speakers.

All these problems are solved by headphones with proprietary wireless dongles and they work great, so why can't Bluetooth incorporate those improvements so we can get them on other devices than desktop PCs?


Also, wireless subwoofers (that come on many consumer TV speaker systems these days) don't have this latency problem either. You just plug them in and they sync to the system and work transparently. They can't have any noticeable latency, or else the bass would be out-of-sync with either the rest of the audio, or if they slowed down the audio to account for latency, then all the sound would be out-of-sync with the video you're probably watching with it.


There are more ways than using bluetooth to transfer digital audio wireless. Probably they are using a custom protocol.


Yes, that's what I mean: they're basically doing the same thing as Bluetooth, but their proprietary implementation isn't saddled with the huge latency problems that Bluetooth has. So Bluetooth seems to be a poorly designed protocol.


Those generally uses a custom 2.4GHz RF protocol, like gaming headsets and mice with dongles.


The bass can be sent with a lower bitrate since the output signal is low frequency anyways.


> Why is Bluetooth so bad?

From what I read online, Bluetooth standart is bloated with outdated profiles and not free for manufacturers to implement. Because of that, manufacturers strap own proprietary extensions on it that only their devices support (e.g. AirPods audio qulity with mic is only good on Apple devices)[1].

Others mention that bluetooth was initially designed for less capble devices, thus suffering from low bitrate and signal strength.

Adjacent discussion here: https://news.ycombinator.com/item?id=40180133

[1]: https://medium.marco.zone/apple-implemented-the-biggest-impr...


Given how much Apple and other manufacturers depend on Bluetooth for their wireless earphones I wonder why no alternative to Bluetooth ever seems to show up.


I think because all the hard work put into open-source bt ecosystem (bluez, pulse, pipewire) makes it "good enough" for average users.


One would think that if some company could credibly exorcise the demons of crappy Bluetooth connectivity, that would be a huge selling point though. I don’t think anyone hasn’t experienced the finnickiness of Bluetooth.


We currently have Bluetooth headphones in the market that are not even using the current spec/API properly. For some of them, the hardware is perfectly fine, if they did use the API correctly, the experience could be almost as good as AirPods are on OSX.


The irony is that even among the same brand they differ vastly:

Beyerdynamic MMX 200 does it wrong: pair up to, uh, I don't know (undocumented!), n>2 devices (I have 4), connects to the last one on power up, but if you want to switch devices, you have to disconnect on the device it has just connected and hope it doesn't connect to yet another you have paired and happens to be in range but is not the one you want to pair with, or you have to disconnect from there too. Confused yet? Yup, it's that bad.

Worse, upon that second disconnect the headset itself initiates a reconnect by going through the MRU list again, so if you disconnect from the second (incorrect) one it might try the first (incorrect) one again since it's now the next in the MRU list, so you actually have to DISABLE BLUETOOTH on each device except the one you want to connect to.

Too bad if one of these devices is in the next room, even more annoying if it's your iPad borrowed by your SO who is now annoyed at losing sound from their movie.

At that point, it's easier to forget the headset in the device you have in hand and re-pair, which is absolutely ridiculous.

Beyerdynamic Free BYRD does it correctly: pair up to 5 devices, connects to the last one on power up, any device in the pair history can force-connect to the headset, yanking out the virtual cord from the undesired device. No interaction required on any other device.

Even better, when pulled out of the charging case they actually wait a bit (a few seconds? or detecting when they're put in ear?) so you can actually invoke some quick setting pane and connect without the connection ever going to an unsuspected device.

Dishonourable mention for Bose QC-35 II, who operates like the MMX 200, only it has two BT radios as an attempt to work around that it's doing it wrong. So, it connects to the last two devices. Unfortunately if I'm walking around the house listening to music and the second-to-last device goes out of range the headset goes "<device name> disconnected" then a few moments later "<device name> connected", which is horrible when <device name> is made out of a serial number (work laptop) and it goes on to spell it out "C. O. M. P. H. 4. 7. X. 3. 9. 9. 7. P. K. Q. L. disconnected".

The only way to prevent that is to go through the Bose app and remove devices from the history, essentially pairing it with one-device-at-a-time only. Oh, it's also great for jump scares when your SO is aping the iPad again and it turns out the headset is connected to it. All of which could be avoided if it behaved like the Free BYRD.


Sounds more like a shitty-software issue. The Shazam function should turn the Bluetooth mics off after the song is identified. Why does it just leave them on?

Isn't that obvious, or is there some aspect to this I'm not aware of (I care about sound quality, so I don't use AirPods)?


It's not just Shazam but any app that uses the mic over Bluetooth. Like if you wanted to have background music playing during a Zoom call, or wanted to wear Bluetooth headphones while gaming and voice chat kicks in when you group up, etc.

It's a very annoying problem because the Airpods actually sound fantastic, but as soon as the mic kicks in, it sounds like crap. Same thing happens with my Sony XM3s or any other Bluetooth headset. The protocol drops to a shitty bitrate to support full duplex.


what you are describing is a universal Bluetooth issue. Windows suffers the same; some Android devices support proprietary codecs to slightly improve the situation but it's still sad we are still here.


Understandable, but in that case what's the value of the utility posted here?


It just automates the manual workaround: It tells your system to use another mic, not the bluetooth one, so that the bluetooth headphones go back to listen-only mode and doesn't have to operate in its inferior full-duplex mode. So you'd use the headphones only for hearing, and your computer's internal mic (or another external mic, like a webcam's or a standalone USB one) does the recording input.

I do that for all my calls and games already, but I just have to manually set it in the OS (and sometimes on a per-app basis). It only takes a second and usually remembers.

If the app were a one-time purchase I'd probably buy it just to avoid the hassle, but definitely not paying a subscription for something that's so easy to do on my own. As a compromise, I'd also be OK with a OS-version tied upgrade pricing, like you pay $x for the macOS 15 version, but when the next breaking OS update comes that requires an update, you can pay $y after the upgrade discount to get the newest version that works with the new OS.


Thanks for the info. And I fully agree about the pricing; that's just dumb.


The default behaviour is designed intentionally to 'degrade to the least-costly codec license' .. since the codecs available to the end user are one of the only ways that different headset/headphone manufacturers can differentiate, doing whats necessary to degrade to the least common denominator allows developers to route around the issues imposed on them by management: namely, don't promote the features of other headset manufacturers, needlessly.


> This is really a Bluetooth issue.

Yes and no. Part of it is also how the OS is used.

Sure if you want to use the mic on your headset you are forced to use a lower quality codec, but on my Fedora I select which profile I want to use on my bluetooth headset[1]. If I set it to AAC or APTX it will not activate the microphone.

And I can easily select which device is the primary device for inputs, outputs or individual apps.

[1] Typically using pulseaudio volume control which is compatible with pipewire (or rather the opposite).


It's not just codecs that are different between HFP and A2DP (although that is a big part of the issue). HFP uses an older way (SCO) of transferring the audio which gives much less bandwidth.

What we need is a new profile that uses A2DP in once direction and in the other for the microphone. I suspect the reason it has never happened is that there's a good chance of causing issues with existing devices that do at least work with HFP.


Samsung phones paired with Samsung earbuds also, on paper, support high-quality audio for calls.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: