I can't believe in that blog they use a simulated video. How hard is it Microsoft to have literally someone talking in a mic connected to two different laptops seriously.
Can a bluetooth mic connect wideband to one laptop and normal to another at the same time? Regardless, the simulation is very accurate IME. It is, after all, all digital anyways.
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.
The trick I'm using (at least on laptops, cannot do this on phones AFAICT) is to change the input device to the laptop's own microphone to get my earphones to not use HFP (Hands Free Profile) and instead stay in a better quality codec (AAC, LDAC, AptX, SBC, whatever your devices agree upon).
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.
> And using the headset mic is probably better if the room is loud or has poor acoustics.
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.
For real quality improvement which is 48kHz stereo + mic, you'll also need GMAP(Gaming Audio Profile) support both on BLE adapter and headset.
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.
Worse yet, I got a new Bose headset with USB C audio support - and the microphone doesn't work at all on either the USB or Bluetooth while USB C is playing audio!
It's been difficult for me to find headphones with LE support. And also I've seen some of them announced support, just to remove it later because the firmware was behaving so bad.
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.
Classic and LE are completely different protocols, from physical layer and up. It must be that it doesn't make a lot of sense for manufacturers to invest substantial effort in it.
> Classic and LE are completely different protocols, from physical layer and up.
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”.
Yes, very frustrating...
I was on the lookout for new headphones that "just work" and LE Audio / LC3 support was a must for me.
One of the more frustrating tech shopping experiences I've had so far.
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).
The WF-1000XM5 beta Bluetooth is pretty good in the latest firmware update. Even though it is listed as beta I use it all the time. And they are pretty decently priced at the moment
Yeah this is a dealbreaker, same with when I found out my sennheiser headphones made me have like 500ms reaction time on audio cues, I get it was an older bluetooth protocol but yeah... no, I'll stick to wired for my pc.
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
I haven't tried a bluetooth device in years, is pairing still godawful? 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. I don't care if it requires the hassle of occasionally having to plug something in to pair the two devices as long as it works 100% reliably.
It's not that bad really, I haven't had a bad Bluetooth Pairing experience in years now, and I keep switching some devices ALOT (phones, headphones, keyboards, mice)
> 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 worst bluetooth pairing experience is with devices featuring "quick pair" "fast pair" and similar.
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...
Sony supports pairing Bluetooth devices via USB since PS3 and Apple supports this since wireless peripherals with Lightning port.
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.
Correct me if I'm wrong, but wasn't NFC at one point considered the solution for such out of band pairing? I think NFC headphones are still available for sale.
Yes, I had an NFC-based speaker once, and that worked wonderfully.
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.
NFC was one possible solution for the "Out-of-Band" pairing defined in the Bluetooth spec.
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...
AFAIK, there isn't any official USB protocol for this, and I think there really should be. Pairing has to be out-of-band to be properly secure against MITM attacks during pairing, and using USB would be such a simple way to achieve that.
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.
Most devices have realized pairing doesn’t need to be so hard.
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.
I love when I’m streaming to the stereo in the living room and my phone decides that oh no I’d prefer to listen to that on the headphones in my pocket.
Yes, it's still a terrible UX. Anybody claiming otherwise is using Apple only, which still has trouble (albeit a bit less than mixed ecosystems), or stockholm syndrome.
Why do you assume innovation and new frequencies are all that related. There are some things new frequencies can help with. Higher bandwidth, lower congestion, but there's also problems with penetration and range. Meanwhile, the protocol itself is packed with modes and features.
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.
On Hardware side the support for 5.x is not bad, Nordic Semiconductor for example is quite fast in adding support to their stack, and the updated stack is available for most (if not all) of their chipsets.
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...
There is a 5000-page standard for Docx I used for a Word export feature. And it was mostly devoid of details and I reverse engineered Word's output files countless times to figure out the actual format. IIRC there was a single 14000-page pdf.
If I remember correctly, the entirety of the original GSM is ~9000 pages, things just got crazier (by orders of magnitude) from there.
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.
Things are far more complicated these days vs the 90s. These specifications still seem to lack important details which you notice if you try implementing the spec.
You don't need to implement the full spec. Most devices only support the parts relevant to them. Hardware in general is very expensive though so I doubt a very long spec that helps you achieve comparability with existing devices is the thing holding you back.
If this doesn't fix the damn "audio quality goes to 10kbps if you also want a mic" I'm going to electrocute the devs responsible with the voltage common BT devices running this stack require.
Why would they fix that in the standard when Qualcomm has a proprietary solution which generates royalties revenue for them? Qualcomm would probably vote against that when it comes up in Bluetooth SIG discussions
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.
Yeah, it's a dilemma. Modern times are no longer suitable for industry-wide standards.
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...
Industry standards were done back then because customers demanded it. When a large customer (big company or government) says that you have to support a standard you support it, and if you don't like it you make the standard better. Even then everyone wanted their own version that wasn't standard because nobody wants you to be able to buy from competition. In turn, sometimes competition reversed engineered you - suddenly you realized you couldn't upgrade anymore unless you were compatible with the competition because customers were expecting compatibility with someone who only partially understands what you did: a few standards were written just so they could explain why this field that was always zero was going to change to a 1 with the next upgrade.
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.
> 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,...)
LE Audio now has GMAP (Gaming Audio Profile) which supposedly solves the problem with HFP/HSP crap. However, almost no hardware out there seem to support it - the only one I’ve read about are some Creative earbuds (Aurvana 2, I think) with a BT-W6 dongle, and I don’t like earbuds (and dongles) so I haven’t tried those. Haven’t found any over-the-ear headset - if anyone knows of something, I would greatly appreciate any recommendations.
WH-1000XM6 should support GMAP according to reddit, however Mediatek PCIE Wi-Fi/BT combos seems have crap drivers and I was not able to make it working. And Intel ones does not work with AMD CPUs(sounds like bullshit, but it requires some Intel proprietary DSP driver to supposedly "decode LC3").
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.
But for many the audio you hear also gets degraded. Like when Windows sets it as communication device instead of headphones and it sounds like a 64kbps mp3s
My information may be a little out of date, but in Bluetooth there was two types of audio. There is isochronous streaming (Headset profile) and audio streaming (Audio Profile). The Headset profile is bidirectional and time-sensitive (packets will be dropped if they take too long), it was designed for headsets as per its name ("communication device") rather than the Audio profile which, although it can be a source or a sink is basically for streaming, where the audio is not time-sensitive as such.
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.
The best you can do these days while keeping to the standard is to use mSBC codec which at least does bidirectional 16bit. It's not too common unfortunately. At least on Linux you can force the codec you want with pipewire. On Mac you just get whatever Apple decides you're allowed.
mSBC is kind of a hack, though. It pushes Bluetooth beyond its specifications and often works, but in my experience it also often causes dropped audio in less than ideal situations (i.e. walking with a Bluetooth headset on).
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.
I don't understand why Apple doesn't do classic Apple of creating and adopting open standards that are slightly better but so obscure that nobody else uses. It doesn't make sense that they're doing features like hearing aids instead of doing an "HSP Plus".
I found it to be a headache trying to get LE Audio to work on my Windows machine. It should provide good audio quality when the microphone is in use but:
- 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.
On Linux it is even worse: there is apparently no USB dongle that would support isochronous audio and recent enough BLE versions. Only some very limited selection of newer PCIe Wi-Fi cards.
That dongle has its own Bluetooth stack and is exposing a standard audio device via USB.
Indeed that currently seems to be the only way, but then the stack need config input somehow, which in case of this one requires a proprietary Win/Mac Software.
try to connect more than 2 devices simultaneously on your mac and "enjoy" the sound you get then. I had this problem with either intel or m* mac and it seems from a search on the Internet that it is widespread to the point that is the normal. Nowadays I only use dongles for mouse+keyboard+headset to avoid such issues, at least the usb-c ones are quite bearable on size you just need to be careful how you put your laptop in the bag, which way up.
That's just a Bluetooth capacity problem. Bluetooth isn't built for high throughput scenarios and "HD bidirectional audio" is considered high throughput in this case.
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.
I'm not talking about anything HD, basic mouse keyboard via BT and simple SBC for the headset. Never had any issues with that combination on Windows in the past before jumping on to Mac 6+ years ago. To add insult on top, I still remember many people telling me to "just do" a full system reinstall to see if it solves the issue.
It depends on how chatty your mouse is. "Gaming" or "high-resolution" mice can spam the BT piconet and cause issues, but a basic office mouse will work without issues.
I am unsure if it's possible, it's just a really bad location for a mic. It is somewhat inevitable to pickup background noise so I suspect you would need a lot of signal processing to filter and reconstruct a decent signal.
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.
I think OP is talking about the compression and bit rate, not the placement of the mic.
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).
Bluetooth doesn't have the bandwith to support anything better. Airpods are as far as you can push it with complete vertical stack control. The magic is in codecs and dynamic switching of them based on whether you are speaking or not.
Is it really that hard to increase the bandwidth in 2025 to get mic quality that doesn’t sound awful? Opus can be really efficient at low bitrates AFAIK.
Airpods have dogshit mic quality from the listener's perspective, just FYI. Everyone in the call might sound nice to your ears, but you sound horrible to everyone else.
You need to use your device's mic on video calls to have a remote chance of sounding semi decent.
I've had a similar experience. I avoid most Bluetooth devices as a result. I can vouch for the CMF Buds Pro 2. They're the first bt buds I've had with good noise cancelling on mic that weren't made by Apple.
I worked in BT almost a decade ago for 4-5 years. My first job. I had never worked close to the hardware. It was nice. Even though the work was not assembly-level close to hardware. Then the rot hit. I saw BT had been there more or less for decades and in one way or another it was going to remain there. The big bad world of backward compatibility and having to support older devices out in the wild was so crucial (as per the companies' POV and I am not judging it either way) that I realised I do not want to keep copying and pasting one line for a driver fix from one code base to 373 for different devices. Given it could have been improved with CI/CD and better source control (maybe!) but it was just not worth it.
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.
BT standard wasn't even that bad, from security stand-point, the worst thing is implementation and maybe only SW implementation.
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)
Does this finally fix the shitty audio quality when using a wireless headset's microphone?
https://techcommunity.microsoft.com/blog/windowsosplatform/c...
This can already be done with LE audio, support is coming slowly.
I can't believe in that blog they use a simulated video. How hard is it Microsoft to have literally someone talking in a mic connected to two different laptops seriously.
Can a bluetooth mic connect wideband to one laptop and normal to another at the same time? Regardless, the simulation is very accurate IME. It is, after all, all digital anyways.
It isn’t.
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.
The trick I'm using (at least on laptops, cannot do this on phones AFAICT) is to change the input device to the laptop's own microphone to get my earphones to not use HFP (Hands Free Profile) and instead stay in a better quality codec (AAC, LDAC, AptX, SBC, whatever your devices agree upon).
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.
HFP has less latency though, doesn't it? And using the headset mic is probably better if the room is loud or has poor acoustics.
> And using the headset mic is probably better if the room is loud or has poor acoustics.
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.
Bluetooth codecs/profiles do not enforce social norms. And I hope they never will.
EDIT: they also won't get rid of useless meetings where people are not mentally present but do other stuff instead.
> Bluetooth codecs/profiles do not enforce social norms
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.
One must follow protocol!
To be fair, even with no noise, the HFP has such bad encoding that it doesn't mean much if the room is noisy or not.
Also the sound isolation tech should be orthogonal to using HFP.
I believe this has already been fixed by LE audio.
But support (on both ends) is quite rare, experimental, and needs to be explicitly enabled.
For real quality improvement which is 48kHz stereo + mic, you'll also need GMAP(Gaming Audio Profile) support both on BLE adapter and headset.
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.
Worse yet, I got a new Bose headset with USB C audio support - and the microphone doesn't work at all on either the USB or Bluetooth while USB C is playing audio!
It's been difficult for me to find headphones with LE support. And also I've seen some of them announced support, just to remove it later because the firmware was behaving so bad.
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.
Classic and LE are completely different protocols, from physical layer and up. It must be that it doesn't make a lot of sense for manufacturers to invest substantial effort in it.
> Classic and LE are completely different protocols, from physical layer and up.
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...
Yeah, my experience has been that bunch of features just don't work when LE is used.
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.
Yes, very frustrating... I was on the lookout for new headphones that "just work" and LE Audio / LC3 support was a must for me. One of the more frustrating tech shopping experiences I've had so far.
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).
The WF-1000XM5 beta Bluetooth is pretty good in the latest firmware update. Even though it is listed as beta I use it all the time. And they are pretty decently priced at the moment
I just bought a separate mic to attach and it works so much better, the modmic or tonor tgp1 are the way to go.
Fix quality?!
It does not work at all!
The only important question.
Yeah this is a dealbreaker, same with when I found out my sennheiser headphones made me have like 500ms reaction time on audio cues, I get it was an older bluetooth protocol but yeah... no, I'll stick to wired for my pc.
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
Old Bluetooth basically uses an equivalent of TCP, retransmissions and all, for one-way, high-quality audio..
Any network / audio / telecoms engineer will tell you how bad of an idea this is.
I haven't tried a bluetooth device in years, is pairing still godawful? 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. I don't care if it requires the hassle of occasionally having to plug something in to pair the two devices as long as it works 100% reliably.
It's not that bad really, I haven't had a bad Bluetooth Pairing experience in years now, and I keep switching some devices ALOT (phones, headphones, keyboards, mice)
> 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 worst bluetooth pairing experience is with devices featuring "quick pair" "fast pair" and similar.
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...
The nintendo switch pro controller is nice for this - plug it in via USB and it automatically pairs to the console you plugged it into.
Sony supports pairing Bluetooth devices via USB since PS3 and Apple supports this since wireless peripherals with Lightning port.
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.
Apple keyboard, mouse, and trackpad work like this too. I’m not sure how you are meant to pair them on non Apple hardware though.
They enter pairing mode after being turned on
Correct me if I'm wrong, but wasn't NFC at one point considered the solution for such out of band pairing? I think NFC headphones are still available for sale.
Yes, I had an NFC-based speaker once, and that worked wonderfully.
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.
NFC was one possible solution for the "Out-of-Band" pairing defined in the Bluetooth spec.
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...
NFC headphones went out of fashion after users’ necks got tired quickly during playback from having to keep their heads near the source device.
/s
AFAIK, there isn't any official USB protocol for this, and I think there really should be. Pairing has to be out-of-band to be properly secure against MITM attacks during pairing, and using USB would be such a simple way to achieve that.
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.
I don't think Xbox uses Bluetooth for their gamepads. It's some proprietary protocol over 2.4Ghz as far as I'm aware.
Most devices have realized pairing doesn’t need to be so hard.
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.
I love when I’m streaming to the stereo in the living room and my phone decides that oh no I’d prefer to listen to that on the headphones in my pocket.
Yes, it's still a terrible UX. Anybody claiming otherwise is using Apple only, which still has trouble (albeit a bit less than mixed ecosystems), or stockholm syndrome.
Pairing mostly sucks with low quality adapters which have all sorts of timing issues. Some decent ones are perfectly fine.
That's how game controllers can be paired - just plug them in.
It is also how the Apple keyboards and pointing devices are paired.
How much more innovation can this tiny slice of 2.4GHZ spectrum support?
It’s wild to me just how much Bluetooth can do. When it was new my mental model had it binned as a “basic comms within 10 feet”.
Last week my kid got to the bus stop before “Controller Disconnected” revealed the PS5 controller was in his backpack.
Why do you assume innovation and new frequencies are all that related. There are some things new frequencies can help with. Higher bandwidth, lower congestion, but there's also problems with penetration and range. Meanwhile, the protocol itself is packed with modes and features.
It's a joke?
What is the latest Bluetooth version having FOSS realizations?
Bluez seems now to have support for 5.4.
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.
On Hardware side the support for 5.x is not bad, Nordic Semiconductor for example is quite fast in adding support to their stack, and the updated stack is available for most (if not all) of their chipsets.
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...
It is the first time I see a specification 3881 pages long!
Check out the 5252 pages long "Intel® 64 and IA-32 Architectures Software Developer’s Manual Combined Volumes: 1, 2A, 2B, 2C, 2D, 3A, 3B, 3C, 3D, and 4" :)
https://www.intel.com/content/www/us/en/developer/articles/t...
Direct link: https://cdrdv2.intel.com/v1/dl/getContent/671200
Or the ~11k pages long ARM specification.
That's actually two specs in one, both ARM64 and ARM32 are part of this.
There is a 5000-page standard for Docx I used for a Word export feature. And it was mostly devoid of details and I reverse engineered Word's output files countless times to figure out the actual format. IIRC there was a single 14000-page pdf.
https://ecma-international.org/publications-and-standards/st...
It's been that way for awhile? 4.0 and 5.0 were ~2.8k pages. Even 2.1 is 1420 pages
https://www.bluetooth.com/specifications/specs/?types=adopte...
All the wireless standards are like that. IEEE 802.11 from 2012 is nearly 2800 pages, and I'm sure the latest version has far exceeded that.
...and the GSM/UMTS/LTE/NR standards are at least an order of magnitude even bigger.
If I remember correctly, the entirety of the original GSM is ~9000 pages, things just got crazier (by orders of magnitude) from there.
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.
UEFI specification is also over 2300 pages long now. For comparison, Open Firmware (IEEE 1275) was 268 pages.
Things are far more complicated these days vs the 90s. These specifications still seem to lack important details which you notice if you try implementing the spec.
A lot of it is classic mode, the spec has accumulated a lot of cruft over the years.
Written by AI?
Sizes like that nicely lock out newcomers from the market, as it can't be entered without a strong financial backing.
You don't need to implement the full spec. Most devices only support the parts relevant to them. Hardware in general is very expensive though so I doubt a very long spec that helps you achieve comparability with existing devices is the thing holding you back.
If this doesn't fix the damn "audio quality goes to 10kbps if you also want a mic" I'm going to electrocute the devs responsible with the voltage common BT devices running this stack require.
Why would they fix that in the standard when Qualcomm has a proprietary solution which generates royalties revenue for them? Qualcomm would probably vote against that when it comes up in Bluetooth SIG discussions
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.
Yeah, it's a dilemma. Modern times are no longer suitable for industry-wide standards.
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...
Industry standards were done back then because customers demanded it. When a large customer (big company or government) says that you have to support a standard you support it, and if you don't like it you make the standard better. Even then everyone wanted their own version that wasn't standard because nobody wants you to be able to buy from competition. In turn, sometimes competition reversed engineered you - suddenly you realized you couldn't upgrade anymore unless you were compatible with the competition because customers were expecting compatibility with someone who only partially understands what you did: a few standards were written just so they could explain why this field that was always zero was going to change to a 1 with the next upgrade.
Bluetooth was developed in a different time.
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.
> 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,...)
LE Audio now has GMAP (Gaming Audio Profile) which supposedly solves the problem with HFP/HSP crap. However, almost no hardware out there seem to support it - the only one I’ve read about are some Creative earbuds (Aurvana 2, I think) with a BT-W6 dongle, and I don’t like earbuds (and dongles) so I haven’t tried those. Haven’t found any over-the-ear headset - if anyone knows of something, I would greatly appreciate any recommendations.
WH-1000XM6 should support GMAP according to reddit, however Mediatek PCIE Wi-Fi/BT combos seems have crap drivers and I was not able to make it working. And Intel ones does not work with AMD CPUs(sounds like bullshit, but it requires some Intel proprietary DSP driver to supposedly "decode LC3").
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.
Every apple user I've seen on meetings using airpods for their mic sounded terrible as well.
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.
But for many the audio you hear also gets degraded. Like when Windows sets it as communication device instead of headphones and it sounds like a 64kbps mp3s
My information may be a little out of date, but in Bluetooth there was two types of audio. There is isochronous streaming (Headset profile) and audio streaming (Audio Profile). The Headset profile is bidirectional and time-sensitive (packets will be dropped if they take too long), it was designed for headsets as per its name ("communication device") rather than the Audio profile which, although it can be a source or a sink is basically for streaming, where the audio is not time-sensitive as such.
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.
The best you can do these days while keeping to the standard is to use mSBC codec which at least does bidirectional 16bit. It's not too common unfortunately. At least on Linux you can force the codec you want with pipewire. On Mac you just get whatever Apple decides you're allowed.
mSBC is kind of a hack, though. It pushes Bluetooth beyond its specifications and often works, but in my experience it also often causes dropped audio in less than ideal situations (i.e. walking with a Bluetooth headset on).
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.
I don't understand why Apple doesn't do classic Apple of creating and adopting open standards that are slightly better but so obscure that nobody else uses. It doesn't make sense that they're doing features like hearing aids instead of doing an "HSP Plus".
I found it to be a headache trying to get LE Audio to work on my Windows machine. It should provide good audio quality when the microphone is in use but:
- 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.
On Linux it is even worse: there is apparently no USB dongle that would support isochronous audio and recent enough BLE versions. Only some very limited selection of newer PCIe Wi-Fi cards.
https://www.sennheiser-hearing.com/en-UK/p/btd-700
Works on SteamOS out of the box and with all the features as far as I can tell.
That dongle has its own Bluetooth stack and is exposing a standard audio device via USB. Indeed that currently seems to be the only way, but then the stack need config input somehow, which in case of this one requires a proprietary Win/Mac Software.
try to connect more than 2 devices simultaneously on your mac and "enjoy" the sound you get then. I had this problem with either intel or m* mac and it seems from a search on the Internet that it is widespread to the point that is the normal. Nowadays I only use dongles for mouse+keyboard+headset to avoid such issues, at least the usb-c ones are quite bearable on size you just need to be careful how you put your laptop in the bag, which way up.
That's just a Bluetooth capacity problem. Bluetooth isn't built for high throughput scenarios and "HD bidirectional audio" is considered high throughput in this case.
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.
I'm not talking about anything HD, basic mouse keyboard via BT and simple SBC for the headset. Never had any issues with that combination on Windows in the past before jumping on to Mac 6+ years ago. To add insult on top, I still remember many people telling me to "just do" a full system reinstall to see if it solves the issue.
> Same problem happens with a combination of earbuds and a smart watch, or headphones and a Bluetooth mouse
Oh! TIL. I will have to keep using that port-hogging mouse dongle then..
It depends on how chatty your mouse is. "Gaming" or "high-resolution" mice can spam the BT piconet and cause issues, but a basic office mouse will work without issues.
I am unsure if it's possible, it's just a really bad location for a mic. It is somewhat inevitable to pickup background noise so I suspect you would need a lot of signal processing to filter and reconstruct a decent signal.
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.
I think OP is talking about the compression and bit rate, not the placement of the mic.
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).
Bluetooth doesn't have the bandwith to support anything better. Airpods are as far as you can push it with complete vertical stack control. The magic is in codecs and dynamic switching of them based on whether you are speaking or not.
But we have Bluetooth doing lossless audio. If we can do lossless or 700kbps+ audio then we can spare a bit of that bandwidth for the microphone.
No, bluetooth has enough bandwidth for 990kbps LDAC, so it should be possible to do 128kbps stereo + 64kbps OPUS mono mic.
Is it really that hard to increase the bandwidth in 2025 to get mic quality that doesn’t sound awful? Opus can be really efficient at low bitrates AFAIK.
How does wifi support multiple gigabit now while Bluetooth can’t support a microphone that isn’t horrendous?
In short - BL uses much less energy than WiFi. It's harder to have speed and be battery friendly at same time.
Airpods have dogshit mic quality from the listener's perspective, just FYI. Everyone in the call might sound nice to your ears, but you sound horrible to everyone else.
You need to use your device's mic on video calls to have a remote chance of sounding semi decent.
I've had a similar experience. I avoid most Bluetooth devices as a result. I can vouch for the CMF Buds Pro 2. They're the first bt buds I've had with good noise cancelling on mic that weren't made by Apple.
LE Audio fixes it, but almost nothing supports LE Audio as of yet.
I worked in BT almost a decade ago for 4-5 years. My first job. I had never worked close to the hardware. It was nice. Even though the work was not assembly-level close to hardware. Then the rot hit. I saw BT had been there more or less for decades and in one way or another it was going to remain there. The big bad world of backward compatibility and having to support older devices out in the wild was so crucial (as per the companies' POV and I am not judging it either way) that I realised I do not want to keep copying and pasting one line for a driver fix from one code base to 373 for different devices. Given it could have been improved with CI/CD and better source control (maybe!) but it was just not worth it.
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)
Any interesting changes regarding BLE Meshing?
We evaluated it BT5.x and the performance was not overly satisfying.
BT standard wasn't even that bad, from security stand-point, the worst thing is implementation and maybe only SW implementation.
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)