Bluetooth 6.2 – More Responsive, Improves Security, Usb Comms, and Testing
Key topics
The release of Bluetooth 6.2 brings improvements in responsiveness, security, and USB communication, but the discussion focuses on long-standing issues with Bluetooth, particularly regarding audio quality and reliability.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
6d
Peak period
143
Day 7
Avg / period
52.7
Based on 158 loaded comments
Key moments
- 01Story posted
Nov 5, 2025 at 7:09 PM EST
2 months ago
Step 01 - 02First comment
Nov 12, 2025 at 12:48 AM EST
6d after posting
Step 02 - 03Peak activity
143 comments in Day 7
Hottest window of the conversation
Step 03 - 04Latest activity
Nov 14, 2025 at 5:32 PM EST
about 2 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
- 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.
Works on SteamOS out of the box and with all the features as far as I can tell.
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.
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.
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.
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.
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).
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.
Oh! TIL. I will have to keep using that port-hogging mouse dongle then..
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.
The built-in iphone microphones are wonderful compared to wired and bluetooth microphones. I think there are 3 or 4 and they do a spectacular job. Why can't we have multiple microphones and do a better job.
You need to use your device's mic on video calls to have a remote chance of sounding semi decent.
...and the GSM/UMTS/LTE/NR standards are at least an order of magnitude even bigger.
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.
Sizes like that nicely lock out newcomers from the market, as it can't be entered without a strong financial backing.
https://www.intel.com/content/www/us/en/developer/articles/t...
Direct link: https://cdrdv2.intel.com/v1/dl/getContent/671200
That's actually two specs in one, both ARM64 and ARM32 are part of this.
https://www.bluetooth.com/specifications/specs/?types=adopte...
https://ecma-international.org/publications-and-standards/st...
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.
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...
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.
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...
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.
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,...)
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.
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.
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.
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.
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.
/s
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.
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...
> 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.
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.
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...
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...
This can already be done with LE audio, support is coming slowly.
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.
But support (on both ends) is quite rare, experimental, and needs to be explicitly enabled.
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.
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 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.
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...
E.g. on my WF-1000XM5, I can't use multipoint connection, lose per-headphone/case battery status, Voice Assistant support and some other details.
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.
They are pretty decent (notable downgrade in most aspects, you do get what you pay for, but good enough for my daily needs). But I was very happy to discover that when plugged in via USB-C, the microphone works over usb with full quality, that's one thing my WH-1000XM5s couldn't do, nor the newer XM6s
So both Bose and Sony need to step up their game.
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
Any network / audio / telecoms engineer will tell you how bad of an idea this is.
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.
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.
EDIT: they also won't get rid of useless meetings where people are not mentally present but do other stuff instead.
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.
Also the sound isolation tech should be orthogonal to using HFP.
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 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.
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.
More modern Airpods use AAC-ELD, which is way way better than mSBC. Still not as good as it could be, but pretty decent and sounds far less muddy.
Basically no support in Windows et al though.
It does not work at all!
Last week my kid got to the bus stop before “Controller Disconnected” revealed the PS5 controller was in his backpack.
Meaning he got 25 feet away when communication stopped, then there was a delay while retries/timeout happened, and then the message when 100 feet away.
We evaluated it BT5.x and the performance was not overly satisfying.
Recently:
https://www.malwarebytes.com/blog/news/2025/07/bluetooth-vul...
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)
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)