I did a deep dive to understand why sound quality is really bad –or reduced, as Apple puts it– when using my bluetooth headphones.
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 decided to work on this project out of frustration, probably shared with more people here, and that's why I'm submitting it.
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
Your app seems nice. I’d love more control over Bluetooth on my Macs. Is this device able to wake this Mac from sleep? If both these headphones are connected, what heuristic should be used to select the input/output?
> Is this device able to wake this Mac from sleep?
Do you mean my app? It doesn't change the wakeup behavior. For my Mac that means it'll wake up when I turn on my bluetooth headphones.
> 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.
It does. I was just venting what I think should be built-in functionality and the void third party apps should try to fill if Apple continues to choose otherwise.
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.
You mention at the end that you can automatically switch input sources with SoundSource. How do you do this? I have SoundSource and it does not do this.
To be honest I haven't used SoundSource myself, but one of the early users of the app I made talked me about it. He mentioned he could select the input/output devices and Mac wouldn't change them when connecting a bluetooth device, as it does by default.
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!
From my own experience, and from what I got from the article, the lower quality full duplex BT is only part of the problem. The major issue is that the mode is selected automatically on macOS.
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 music, that's just not true. AAC is widely supported and sounds transparent to me; I'm not sure if I could detect SBC at high bitrates either.
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.
Yes, with the A2DP profile (high quality music) things work good enough for me not to notice. Maybe you could hear some differences on a side to side comparison, but it's good enough.
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.
Opus provides excellent voice quality at 10 kbps (less than 1/6th of what PCM uses at 8 kHz), at a latency of 26.5 ms, so it's definitely not a technical problem for HFP either.
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 actually didn't know about Opus, but having read a bit about it, how aren't we using that codec for all things audio? It's open source, has good platform support, quality seems to similar to AAC, it could be used for HPF. What's stopping the adoption of Opus in Bluetooth standards?
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.
I have the pixel buds A-series, and using my pixel 7a I can feel the quality going down when on a call. It might be just the latest buds, or my pixel 7a not supporting the codec, or the HFP not being set to use it ¯\_(ツ)_/¯
It is a general issue of Bluetooth. And the solution are improved codecs for HFP. Seems like people are skeptical if BLE Audio and L3C can make a big change.
Let us see. Ah hear. Pipewire seems to support it already on Linux.
I agree improved codecs is one of the solutions. I think other solutions could appear if Bluetooth wasn't restricted to a 3Mbps bandwidth, which seems to me –I have no information on this– it's a very outdated constraint.
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.
Isn't it possible to use LC3 over Bluetooth Classic HFP? And isn't LE audio advertised as flexibly supporting multiple streams, much better than Classic? That means, it's just bad implementations, not a principal limitation?
Apparently some phones and headphones support it now, but oddly enough there is absolutely no information to find about the specific level of support.
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.
Probably for the same reason that most Bluetooth keyboards (with which we type high-sensitivity passwords!) still use a quite insecure encryption algorithm, i.e. some combination of incredibly bloated specs (Bluetooth alone is thousands of pages) and slow industry adoption of said complex specs.
Add to that the additional patent risk inherent to audio codecs, and you get the status quo.
> Also, I don't quite understand why nobody worked around this yet?
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...
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.
I don't think it's accurate that there is "no way" to "prevent your mac from using the headphone's microphone." There are several workarounds like creating an Aggregate Audio Device in Audio MIDI Setup [0] or disabling HFP [1]. I wish you success with your paid utility though.
I popped in here to post this. The aggregate audio device setup in the Midi setup assistant works really well for me. There is some loss in quality still, but definitely not as bad as before.
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.
Perhaps such an app is useful, but I've actually found the macOS behaviour desirable. I get good quality unless the mic is used, which I only do deliberately.
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.
This is the exact use case I have, and the frustration of not being able to select what I want made me create the app. I'm really surprised this functionality doesn't come with the Mac, but I couldn't find a workaround that didn't involve a manual switch somewhere.
Yeah, Windows is a million times worse and more confusing in this regard. My favorite is even if you're using an external USB mic which allows you to use the "Stereo" profile on the headphones, until Windows somehow hijacks the audio with a Teams or Outlook notification and mutes all of the audio that actually matters until you clear the notification.
I feel like this has gotten worse with Windows 11. Now even with the headset microphone disabled in the new Windows Settings screens (I use a separate USB mic) some apps (mostly games) still insist on activating the "headset" profile and switching things into 1800s telephone mode.
Do you know how bluetooth is handling play/pause buttons while listening?
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.
I didn't know about the AVCTP, but I completely agree on the possible alternatives Bluetooth could use.
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.
A2DP would not be a good choice for real-time audio, since it's optimized for quality and defined latency rather than low latency. It does so by using reliable transports which use large retransmission buffers, making latency much worse.
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.
And then people say "but why, bluetooth is so nice, get on with the times" when you complain about how hard it is these days to find a phone with a headphone jack.
Fortunately, I never print anymore. But I use that freaking wireless protocol multiple times a day.
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.
I personally almost never use my 3.5mm audio port and would gladly take one more USB-C port instead of it, just like for the HDMI port on my MBP.
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.
Every port increases the wiring complexity on and size of the mainboard, as well as the bill of materials.
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.
Unfortunately not, as far as I can tell (Apple took away the debugging option from the Bluetooth menu a while ago, but at least the first AirPods still used mSBC for HFP).
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.
macOS is frustrating with Bluetooth. I use an external USB microphone and would like to lock it. Still, any time I put my AirPods on, it auto connects for both listening and microphone, even though I have a much better quality microphone already selected. So I have to open the Sound settings every single time, which is incredibly frustrating; please just let me prioritize which device I prefer using and stick to that.
ToothFairy for macOS is what I've been using to handle this. It has an advanced setting for headphones that "Improve sound quality by disabling audio input from device". It's always good to have multiple tools out there to solve problems like this.
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).
This made me think about the mic on my $300+ headphones. It's probably even a good mic. However, because they will only be used via bluetooth, it will most definitely be used under a HFP mode, which means that a probably decent audio signal from a probably decent mic gets completely destroyed. Nice.
I've occasionally seen gadgets that have non-bluetooth wireless. (For example, a gaming mouse.) Is there anything good for headphones? Since I play an instrument, I'd like both low latency and high quality.
I have to regularly restart my MBP because after a few days, when I'm using my AirPods, my volume buttons lag the entire system to a halt, and simultaneously get stuck. Nice way to blow out my eardrums. I just don't use the buttons anymore.
this is going to sound insane, but: when that happens, try doing `killall Dock` in terminal and see if it fixes it. I have no idea what causes it, but it lets you avoid a reboot.
The other annoying thing OS X does is launch iTunes when Bluetooth headphones are connected. This steals audio from whatever the Bluetooth device was already doing, at least for me. iTunes can't be removed or disabled, apparently.
This has never happened for me, with AirPods at least. However, sometimes when I press the media keys (play/pause, forward, backwards) iTunes opens. Maybe your headphones are automatically activating the play button?
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.
The blog post discusses this. They have two modes - one for bidirectional audio (headset mode) where the bitrate is reduced significantly - and one for regular audio. It is made worse by the fact that sometimes the higher quality codecs are not used ie aptx.
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.
> 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.
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.
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?
Ouch. I'm sorry about this. I've had users on Sonoma report this. It seems they made it harder to make Gatekeeper happy. I'll reach out to your email directly to figure out how to fix it.
Can't you just go to system preferences and privacy and security and then scroll all the way to the bottom and then click open anyway or something like that?
It would be a lot simpler to say BT audio has two modes, one is listen only and higher quality, the other is two way but lower quality. Sometimes your device gets stuck in the wrong mode.
I tried this as well and didn't work for me. Maybe it works for other people?
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.
I did some similar research when the airpods first came out and found the same thing "its needed for low latency" but never thought about using the laptop mic, having a huge facepalm moment right now.
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.