What’s the status of audio on modern Bluetooth? The only decent mic+audio configuration I’ve ever experienced is AirPods on apple devices, anything else sounds terrible when the microphone is activated.
replies(8):
- I have to have BLE v5.2 at least on my Windows device - It must have isosynchronous audio support (which I believe is an optional feature in the spec)
- The headset must have the same features too.
Then it is a question of which audio codecs are supported on those 2 devices. It's quite messy to be honest.
I don't think any ear pod style mic exists that isn't completely outclassed by a mic I could pickup 2 decades ago at Walmart for $10-$20.
We evaluated it BT5.x and the performance was not overly satisfying.
The form factor doesn't help either, the mics are tiny. Phones have the benefit of a bit more space and a much more practical location.
https://www.bluetooth.com/specifications/specs/?types=adopte...
...and the GSM/UMTS/LTE/NR standards are at least an order of magnitude even bigger.
Sizes like that nicely lock out newcomers from the market, as it can't be entered without a strong financial backing.
When the mic is turned on, many headsets go from sounding good enough to sounding absolutely horrible. Something about switching from A2DP to HFP, and sharing the bandwidth between the incoming audio and outgoing audio.
AirPods are impacted much, much less, largely I think because the AAC-ELD codec is decent, and Apple OSes switch the audio from stereo to mono when the mic is on (which seems like a no-brainer IMO, but I guess not all operating systems do this).
So yeah, the isochronous streaming mode is much lower bit rate but thats probably why Windows sets it as a communications device, because it needs that mode.
Its difficult to know exactly, but I use a Logitech Zone Vibe 125 headphones with microphone and find it works fine for phone calls and listening to audio. However, I am not an audio nerd and neither are the people I speak to using it. I never had any luck with in-ear devices.
https://www.intel.com/content/www/us/en/developer/articles/t...
Direct link: https://cdrdv2.intel.com/v1/dl/getContent/671200
But in general there is very little support for 5.4 from the hardware side right now. I looked into ESLs (electronic shelf labels) which should be directly supported by 5.4 but you find almost nothing. Would just be nice if one could take any manufacturer's ESLs and they would just work. Right now there is a plethora of different standards.
I wont hold my breath for 6.2 support. There are not many devs on bluez and on the kernel side.
Most stuff now will happily access the first thing that connects to it while in pairing mode. I have many devices that a switch my headphone pairing between with ease.
Same goes for A2DP with a remotely decent compression algorithm which doesn't sound like crap
I'm cynical enough to believe that these obvious huge missing parts of standard Bluetooth aren't accidental. They've surely noticed.
Works on SteamOS out of the box and with all the features as far as I can tell.
The best pairing experience is with devices that have a pair button or let you hold down the power button to enter pairing mode. Although I've now ended up with headphones (Creative Zen Hybrid (Gen 2)) that have this, but also decide to just unexpectedly enter pairing mode when you disconnect all devices from it...
https://ecma-international.org/publications-and-standards/st...
Apple has a proprietary USB protocol for pairing its own wireless keyboards, trackpad and mouse, and Microsoft and Sony have proprietary protocols for their respective gamepads.
Televisions(eg.: LG) where you're unable to turn BT off. With that knowledge, you can buy cheap device which is normally used for development and analyzing of BT communication.
And with that device, you can spam any TV around you with fake BT connection requests, TV is basically unusable during this time and best thing, this cannot be blocked :D
(only way to turn BT off on LG TV is with you getting root and downloading homebrew app, which of course degrade the use of your TV remote, because it uses BT)
This can already be done with LE audio, support is coming slowly.
Haven't checked in a while, so I don't know if is there something reasonable now that doesn't cost like $500 or so.
However the protocols to do that are all proprietary and mutually incompatible. At least the PS3 protocol has been sufficiently reverse engineered so you can plug a DualShock 3 controller into a Steam Deck and have it just work wirelessly afterwards.
That said, even if a company which already launched its product would upgrade their stack to a newer version, it's unlikely that they would spend the money and resources to re-certify for a newer BT-version unless there's an explicit need for it. They rather treat this as a maintenance release of the existing certification...
So it might be that there are more devices with 5.4 BT-stack out there than it seems...
Then the rest of the software world hit hard, and I saw, yet again, that the grass is green and that at least the world of BT had epic job safety, slow but stable growth, and best of all - no rush to fix something in the next 37 mins or millions of ad revenue will be lost.
But I see, as I had guessed, not much has changed "more or less" :)
I blame Apple as well, or both Apple and SIG for not making adoptions faster. But then Apple had nothing to worry about when it came to backward compatibility. So "Apple-rest" never really happened in a meaningful way, and whatever happened happened quite late.
(By the way there are more details on SIG portal if one is interested. Here are some https://www.bluetooth.com/bluetooth-core-6-2-feature-overvie... and https://www.bluetooth.com/blog/just-released-bluetooth-core-... and maybe follow from there)
Landed on the JBL Tour One M3, they sound okay and support LE Audio. They have some interface problems (Auto-Pause and automatic speech detection is way to sensitive for me) but you can tweak it so it does "just work" (mostly).
> I wish they would give you the option to pair through USB. Just plug in the host and peripheral and press the pair button, and it should automatically negotiate pairing.
This is called "Out of band" (OOB) pairing and supported since Bluetooth 4 iirc, it's a method which allows key exchange using a different bearer than Bluetooth.
It's implemented quite famously on the Sony Playstation 3 and 4, where BT-pairing is done by connecting via USB and pressing the "Playstation" button.
On other Bluetooth-devices it's mostly not implemented because apart from the limited support for OOB pairing over USB on the host-device, it would require the peripherial device to also have a USB data-interface in control of the Bluetooth chipset.
So more complexity and cost, to solve a problem which barely exists anymore.
The spec. allowed to exchange encryption keys with a different method than Bluetooth, Sony is using it on the Playstation to perform BT-pairing via USB.
Commercially, NFC was mostly used to initiate pairing, by having a NFC Tag on the accessory which stored the Bluetooth address, and a device scanning the tag would initiate pairing with the device directly.
The pairing itself is technically still done over Bluetooth, which is nowadays mostly a matter of confirming the operation...
Oh yeah I also LOVE Teams and Meet completely breaking my mic forcing me to use some other mic because it doesn't work with the one on my headphones half the time
Up until the 2000s, industry standardization groups were formed by companies which acknowledged that they need to team up and cooperate with each other to establish a mutual standard across several market-segments.
Nowadays we have companies who participate in those standards but don't contribute their work back to it, in hopes to secure a competitive advantage with a closed ecosystem.
What happens instead, is that they force other equally-large players to develop another proprietary standard to match them, and now the standards body is unable to find common ground between all members anymore.
Apple is the most egregious example of this, extending the Bluetooth spec in proprietary ways and not contributing any substantial implementation of it back to the standard (proprietary fast-pairing, linking BT-pairing to the Apple-ID instead of the device,...)
In today's times, Bluetooth wouldn't even be a standard. There would likely be equivalent wireless specs from Apple, Google/Qualcomm and Microsoft/Intel, none of them would work properly with each other because each team has its own set of accessories to sell...
mSBC is worth a try if you haven't already tried it, but it's not a real solution. Bluetooth LE Audio does provide a fix, but real hardware that supports it is hard to come by.
Same problem happens with a combination of earbuds and a smart watch, or headphones and a Bluetooth mouse, depending on the interference and chattiness of your devices.
It does not work at all!
Any network / audio / telecoms engineer will tell you how bad of an idea this is.
You'd go up to the speaker (which you had to do anyway to turn it on), and you'd touch the phone to the NFC part. That would turn it on and pair it with this specific phone. The whole thing took less than a second.
It was great for sharing the speaker among family members, when different people used it at different times, each with their own phone.
This was in ~2015, I had a Galaxy S4 at the time, no idea whether this works with iOS or modern Android.
That's actually two specs in one, both ARM64 and ARM32 are part of this.
That's comparing apples to oranges, though. Those standards also specify the interaction between network components, not just between your phone and the network.
Mobile phone standards are more like the entire RFC collection than like the 802.11 specifications.
In those days, there was no single dominant phone or chipset manufacturer in most countries, much less globally. The phone was a device to access your carrier's plan, maybe with a few nice goodies on the side. Which plan you had was much more important than which phone you had. Phones were like cable boxes in many ways, most people don't know who makes their cable box, all they care about is whether they can watch ESPN and for how much.
Nowadays, you have three OSes that really matter, iOS, Android and Windows on the desktop side. Most people will only ever use at most two. You don't quite need a standard as much in an environment like that.
Which makes sense when you know it started life[1] as a separate protocol called Wibree by Nokia, which was specifically designed[2] to be usable by Bluetooth RF gear:
A major tenet of their design was that “it can be deployed with minor effort into devices already having Bluetooth, e.g. cellphones” with the added requirement that a “common RF section with Bluetooth must be possible”.
[1]: https://en.wikipedia.org/wiki/Bluetooth_Low_Energy#History
[2]: https://www.ijert.org/research/wireless-communication-with-w...
I've tried multiple combinations with my WH-1000XM6 and WF-1000XM5, but nothing works stable on Windows. Linux requires hand-patching bluez and friends which also failed for me. Android does not support GMAP and just when using LE, a lot of messengers unable to detect it properly(Google Meet works, Telegram and Viber does not).
I've finally gave up on that idea. Just thinking about fact we cannot use duplex wireless audio in 2025 pisses me off so much tbh.
Sound quality for my calls on both sides improved dramatically! Since I've discovered this, I tell all my colleagues in our zoom meetings to switch microphones and it's immediately better for everyone on the call (not just the user that was using HFP).
This is because if you use the hands free profile, it'll use a codec that encodes your voice in a terribly bad bitrate, and even worse, the sound you hear in the headphones is also using a terribly low bitrate.
They should finally fix HFP (Hands Free Profile) spec as it's literally impacting call quality for billions of people.
Edit: apparently LE audio is a thing, but device support is still terrible.
You need to use your device's mic on video calls to have a remote chance of sounding semi decent.
Not to mention the combination of "microphone in the laptop body + person who doesn't turn off their microphone when they're not speaking + person who seems to never stop typing during a call" tends to be distracting at best.
It’s that when you have legal agreements with guilds and unions, even produced promotional material can be considered a production requiring minimum staff (I.e. makeup, camera technician, etc.) On productions, any person wearing multiple hats is tightly controlled.
A cartoon I watched growing up ran into this when they needed to insert live action, so they deliberately recorded at 1 FPS for that episode to make it ineligible for budget reasons (https://phineasandferb.fandom.com/wiki/Tri-Stone_Area).
If you’re ever wondering why a company can’t do something simple and obvious, it’s probably due to a legal agreement.
Guess I gotta correct my assumptions then, I clearly thought they did.
Regardless, microphones built-in the same body people type against will remain a personal pet-peeve for me.
Who is "You" in that context?
[Large developer of a product]: You DON'T need a standard because you can strongarm your proprietary implementation into "your" standard (which is what is happening, as I wrote above), and as long as the user only buys products sanctioned by you, all is fine.
[Small developer of a product]: You DO need a standard because you are only able to participate and compete if you are able to match the experience of the large players in your market (which might also be the ones owning the platform your product connects to). For this you need equal access to those proprietary standards they may have created. This is however not in the interest of most of the large players, so you are actually not able to compete on equal grounds.
[Product consumer]: You actually WANT a standard, because a standard ensures interoperability across different types of products and vendors, and prevents vendor/ecosystem lock-in.
In these "different times", this fair and competitive market was a side-effect from this need for vendors to align in order to standardize across different areas, because they understood that "they cannot do this alone".
In the "nowadays times", there is a handful of companies large enough to do it alone, and they have an active interest to prevent the creation of an industry standard ("I want to enter the watch market, so I create a standard to connect my platform to a watch, AND I create a watch to control this value-chain end-to-end).
This "side-effect" of a competitive market is now gone and is ACTIVELY prevented by this handful of companies (see adoption and proprietary expansion/restriction of Bluetooth, WiFi-Direct, NFC,...)
Last week my kid got to the bus stop before “Controller Disconnected” revealed the PS5 controller was in his backpack.
Maybe not a problem with Macs, but call quality on most laptops using the built in mic is bad enough that people on the other side will have a bad impression of you.
I currently have a bluetooth mouse, a bluetooth keyboard, and bluetooth headphones all on the same device and haven't had any issues. On a different computer with a different bluetooth chipset it would have issues with audio when I moved my mouse around a lot.
My biggest annoyance with Apple devices is in software, that AFAIK there's no way to prevent macOS from pairing to any Apple Bluetooth device connected via USB, even if it's already paired with another device and you only intend to use it via USB.
I actually told him many salespeople get this completely wrong and sound like an absolute Muppet on their expensive headsets without even realizing it and explained to him that anything Bluetooth is basically never going to sound amazing. There’s a lot of snake oil in the market. I got some nice Sony earbuds recently. Tried it once and I was barely audible apparently. That’s supposedly a high-end option. It’s OK, I got them for music and podcasts and wasn’t expecting much for calls. But it managed to underwhelm me on that front. The weakness is Bluetooth and the standard codecs supported on Mac/Windows. You are basically screwed no matter what BT headset you use. For phones, it depends.
Apple fixes this with AirPods by doing a proprietary codec and probably quite a bit of non-trivial sound processing. None of that is part of the Bluetooth standard, and what little is supported in some newer codecs typically does not work in Windows/Mac. So it will still fall back to that low-bitrate codec that distorts your voice and makes you sound like a Muppet.
If you need to use a phone, getting a USB-C headset can be an alternative. Not that many wired headsets these days, sadly. Even Apple now uses USB-C. And both Android and iOS support most USB-based sound equipment.
I take most calls with my Mac. I configured an aggregate device with the MIDI tool so that my headset doesn’t hijack the microphone. Nice little hack if you have some decent BT headphones. On a Mac, the microphones in the laptop are likely way better than the vast majority of headsets. And that’s before you consider the latency and heavy compression Bluetooth adds to the mix.
AFAIK, PlayStation wireless controllers are Bluetooth-only, but the DualSense (PS5) controllers use some proprietary extension not supported on Windows for haptic feedback over wireless that's sent via standard audio protocols over USB.
I think maybe there's like on one or two people who have gotten neard daemon doing Bluetooth OOB with Bluez, but it's very obscured in results or their reports have bit rotted off the net.
I recently got the Tour One M2 and was pretty disappointed with the audio quality (both normal bluetooth and LE audio). Noticeably worse than my previous wired headphones, which were also cheaper. The touch controls are also terrible, and I dont like that noise cancelling is on by default with seemingly no way to change the default setting.
You can try an Android App like NXP TagInfo to read the contents of that Tag and show you what's inside of it, my expectation is that it's just a basic NFC Tag...
Do you have any sources for that claim?
As far as I understand (and based on what I've seen in some Bluetooth debugging menus at least a few macOS versions back), for HFP they just use regular mSBC.
That's an optional codec for HFP (while SBC is mandated for A2DP), and a step above absolute potato quality G.711/PCM u-law, but still part of the regular Bluetooth HFP specs.