Why is Bluetooth sound quality bad on my Mac
recadio.com
recadio.com
I read through Apple's documentation, Bluetooth standards, and Wikipedia articles for different codecs, and I tried to summarize my findings in this post. The post talks about Mac, but it's probably relevant to other OSs as well.
As a disclaimer, I want to state that I've made this investigation for fun, learning, but also profit. I'm working on a Mac app that aims to help with the audio quality when using bluetooth headphones. I decided to work on this project out of frustration, probably shared with more people here, and that's why I'm submitting it.
I hope you find it interesting.
Frustration is great to initiate action, but usually doesn't work well as a sustained source of motivation. Sometimes it's just a matter of rephrasing the situation. You have an appreciation for audio quality - let that (rather than the frustration) guide Recadio's continued development. Wish you best on the journey <3
Interesting enough, no codec-related issues if you use Bluetooth headset with mobile phone.
> If both these headphones are connected, what heuristic should be used to select the input/output? My app remember your choice for a given group of connected devices. That means that, if you haven't chosen anything, the default behavior will take place. If you select one of them, it will remember the choice and auto-switch to that one when the same group of devices is connected. I hope it makes sense.
For instance, I turn on my Sony 1000MX4 in the living room to listen to music on my iPhone. The iMac wakes up in the office and if it has an YouTube video paused in Safari or the Music app in the foreground, the input won't switch to the iPhone unless I manually change it on Sony's app.
Or, I have a meeting and need to use a decent microphone in order to be heard, so the wired mic connected to the Mac should be selected when the MX4 is off, but instead it reaches for the AirPods that are sitting in the bedside table in the bedroom. Stuff like that.
It's not exactly what my app does, but I thought it could fix the auto-switch for many users.
I'll definitely update the post if SounceSource cannot be used to fix the auto-switch. Thanks for the heads up!
This is simply a Bluetooth issue and why Bluetooth is bad if you care about audio quality.
I never had this problem with Pulseaudio and Blueman, for example. The microphone isn't even registered until I manually change modes for the connection.
Another annoying thing is that the mac is so aggressive when connecting to devices over BT. I regularly have to restart stuff because my mac hijacked the connection. It seems to do it even when the lid is closed.
For voice/HFP, I agree, and LC3 can't arrive soon enough. I'm actually really surprised Apple doesn't use anything proprietary/better than mSBC for their AirPods.
The real problem comes with the HFP profile. Lack of decent codecs, and bandwidth limitations of Bluetooth make it really hard to solve. Not to mention the vast majority of devices you own can't upgrade codecs, or just won't because there aren't incentives.
There's always the risk of unknown patent claims, but the same is true for any other codec not older than 15 or so years.
I can only suspect why it's still so rare, but my guess would be either a fear of unknown patent claims, a lack of readily available hardware implementations, or a combination of both.
And if you read the article, it is an Apple problem since macOs chooses the wrong bluetooth profile.
Let us see. Ah hear. Pipewire seems to support it already on Linux.
I mean, 4G has existed for over a decade and it supports 100Mbps bandwidths. With that bandwidth it could use uncompressed audio and support stereo for both output and input.
Regarding LC3, I've read people complain that it forces the Bluetooth Low Energy, removing a few features like multi-point connection and a few others.
I can't believe we're in 2023, WiFi can do 40Gbps, but Bluetooth still has no reasonable high quality, bidirectional audio mode.
Skype, Zoom and the like have been around for ages. The usefulness of high quality voice communication is very, very old at this point.
So what's the holdup?
Also, I don't quite understand why nobody worked around this yet? I never looked into Bluetooth properly, but it's a protocol that like USB can present a set of capabilities and negotiate features, right?
What's stopping anyone from say, supporting a higher bandwidth mode of HFP, or offering sensible modern codecs like Opus, while remaining compatible with the normal standard?
Judging by the incredibly fractured state of bluetooth codecs in general I'm gonna blame patents and the completely fucked up and maligned governance of the bluetooth standards body.
You only have to take one glance at the professional performance space to understand that the problems were solved before bluetooth even existed, and today there are completely free and open codecs in use in wireless mic and in-ear-monitors that beat the speed-of-sound latency of a speaker 15 feet away. That's the point of professional monitors, after all.
The entire bluetooth ecosystem is the most gigantic tech clusterfuck there is. It's amazing it even works.
I find that my life contains less frustration when I act as though it doesn't work.
Add to that the additional patent risk inherent to audio codecs, and you get the status quo.
Apple implemented proprietary codec for AirPods to have high quality audio with mic when connected to macOS/iOS device. With other host AirPods fallback to A2DP/HFP, and macOS with non-Apple headphones has the same problem, as described in this blog.
I think Bluetooth protocol spec is not free and because of that ecosystem is very fractured.
I hope the situation will improve with Bluetooth 5.3s LE Audio/LC3[1][2]. Regardless, it's not backwards compatible with existing Bluetooth devices...
[1]: https://www.reddit.com/r/bluetooth/comments/1746e02/does_blu...
[2]: https://www.soundguys.com/bluetooth-le-audio-lc3-explained-2...
From what I've read in the last few days researching to write the post, it feels like Bluetooth was designed under some constraints 20 years ago, and it keeps using the same constraints today.
Also, the companies listed in the HFP specification don't make me think they're trying to optimize for the actual phone call scenario, not using a bluetooth headphone with your laptop.
[0] https://www.reddit.com/r/MacOS/comments/n6trw3/comment/gx98u...
[1] https://discussions.apple.com/thread/7495115?sortBy=best
It also solved a problem I was having where the input volume would progressively get quieter as I was speaking making it so no one could hear me on calls.
The reason I didn't add it is because I tried it and didn't work for me, so I just forgot it was even an option.
Thanks for the heads up!
The Windows behaviour is what really annoys me. When the mic is used, the headphones switch profile. But Windows continues to send output to the audio device for the other profile, which means you get no sound at all. You have to manually change the audio output device every time the mic is used to be able to have audio.
IDK, when I used a Mac at work ~2y ago every time I connected my headphones it would prefer them as the audio source. I have a USB mic always plugged in but I couldn't find any way to prevent it from switching to the headphone mic. I always had to many switch the input source after plugging in my headphones before I joined a call or something.
By using a different protocol named AVCTP, while the stream uses AVDTP (with A2DP on top).
A nice way to fix this issue would be to have a kind of bluetooth bonding: 1 connection for receiving audio/video, and the other for sending audio from the mic. That would use up to twice the bandwidth, so fewer bluetooth devices could be around maybe, but it would be nicer.
The real issue, I think, is mostly the fact that supported codecs are all in firmware of the chips used in the headset and laptop, and cannot be upgraded. Otherwise we could have used Opus for voice codec a long time ago.
From what I've read in the last few days researching to write the post, it feels like Bluetooth was designed under some constraints 20 years ago, and it keeps using the same constraints.
For example, it's unreal to me that the bandwidth for a Bluetooth connection is around 3 Mbps when we've had 4G with 100 Mbps for over 10 years, let alone 5G at 20Gbps.
And yes, the codecs in the firmware is really bad, although very convenient for the companies selling devices I guess. There aren't enough incentives there for the change.
I charge my headphones once per month, maybe twice. I'd gladly charge them once per week if that means I get nice audio in and outside calls.
An analogy would be Shoutcast (MP3 audio streaming, mostly used for web radio) vs. RTP (mostly used for real-time communications these days): Both have their strength and weaknesses.
Whenever I marvel at the amazing tech we have, I remember that this remarkable culture chose to inflict Bluetooth on itself.
Or surprisingly low standards for “nice”.
(Oh, and: printers. I bet you hate printers more).
For all the hate that printers get, it’s a deceptively hard problem that they tackle:
- They must pull a single sheet of paper perfectly straight out of a stack. That’s hard even for dextrous human hands.
- They must use a fluid that dries instantly yet won’t clog even if unstirred for months.
Having said that, the reason printers went WiFi instead of Bluetooth is that the combined rage towards such a device would be enough to collapse it into a black hole. And you don’t want a singularity in your everyday office.
An USB-C to 3.5mm adapter with excellent quality costs about $10, and I can just keep it permanently plugged in to my headset for the very few times I do need it.
A USB-C hub costs much more and supplies less power to downstream devices than two dedicated USB-C ports would.
It's probably minuscule for something like 3.5mm audio (even though analog noise on the board might be a concern), and the computer already needs a DAC/ADC for its built-in speakers and microphone, but when in doubt, I'd rather take a port that I can convert to another using a cheap adapter than a fixed-purpose one I never use.
My guess is they’ll ditch it if/when they make a water proof laptop. No ports at all, induction charging only. Johny Ives's dream after retirement.
https://shkspr.mobi/blog/2023/09/better-bluetooth-sound-qual...
On Linux, I can manually select the codec I want to use from a GUI drop down.
This is really surprising to me: They clearly don't mind licensing AAC for A2DP/music mode even though SBC is free and the only required codec, so I don't understand why they don't include at least something proprietary for AirPods to Apple device use, or now LC3.
I'm not surprised this catches people off guard. I'm usually among the gadget folks and was intellectually aware of the A2DP/HFP situation, but hadn't put it all together until I tried to use my new headphones (which support AptiX, etc), went to play a video game, and my (Windows[0]) computer flipped me to HFP, destroying the game audio to my headphones. It was at that point that I understood why the console makers shied away from "just using bluetooth" for their headset channels[1].
It was a new laptop that has some rather slick features you can apply to the mic array which causes it to only pick up the voice of the person directly in front of the laptop, or limit it to the people in the room (but not, say, televisions/stereos/PC audio). If I want the higher quality audio from my headphones, I just use my laptop's mic; it sounds as good to everyone else.
It's a shame for my phone, though. Many conferencing apps support High Definition audio and there's a not-always-small difference between the Bluetooth and USB versions of some conferencing devices.
[0] Which, AFAIK, doesn't support AptiX; but my phone does.
[1] I haven't looked into this in three years or so -- I recall something about PS4/PS5 supporting certain Sony headphones and there are plenty of wireless headphones that work with a USB stick (along with at least one on the Xbox platform [Turtle Beach] that required no USB stick, licensing/utilizing whatever the wireless controllers use -- since most/all have a 3.5mm jack -- for communication).
I haven’t tried them, but several YouTubers have reviewed them in a positive light.
I've never looked into it, but I'd be surprised if no one has made a USB-C interface that has a transceiver for them.
I think this isn't popular because no one wants to wear a beltpack for their headphones at home.
I've used both HyperX and Steelseries headsets that have much better audio with the mic on that my more expensive Bose headset does.
- Uncompressed 8-bit, 8-kHz PCM: Potato quality, equivalent to a legacy digital phone line)
- mSBC: A latency optimized version of SBC, offering at least 16 kHz thanks to some level of compression. (Sweet potato quality?)
Make sure that your headset supports at least the latter to make HFP mode slightly less unbearable!
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.
> “Recadio.app” can’t be opened because Apple cannot check it for malicious software.
Again, sorry about that.
End of explanation.
>defaults write com.apple.BluetoothAudioAgent "Disable HFP" -int 1
When I connect my headphones and switch to the microphone, the same crappy sound comes up. I had tried before with the checkbox in the bluetooth explorer to disable HFP, but also didn't work.