Ask HN: Bluetooth kinda sucks. Why don't we have something better?

There's a long list of comments in that thread discussing "why" it's the case, with most simply saying "it's difficult." I disagree.

I think it's the same reason why so much of our software is poor quality: taking something from "works" to "works well" is a cost sink. It will cost you and yet doesn't add much to the bottom line to compensate.

It's sad that my family uses the available Bluetooth devices less than if there was a wire we could just plug into.

We think of technical innovation as a straight line forward but sometimes it goes back the other way.

I have spent some time wondering this same question - what I came to - Bluetooth is most likely a protocol spec where by any and all action the protocol can take is defined. The implementations are left to the vendors such that for one Bluetooth spec we get N physical/software implementations. So we're always taking a device from vendor X and trying to pair it with implementations from vendor Y and Z. We're now talking about 3 different versions of the same spec here more or less.

Cross vendor implementation of software is where I see a big potential for problems. As a protocol specification Id imagine all this has been thoroughly thought out. Where the rubber meets the road in the software, its probably not been so faithfully implemented (it works with my laptop - SHIP IT!).

Just my thinking on the backside of finally getting a new phone paired with my car.

Most of the problems seem to be poor implementations, because what's the motivation for, say, a car company to get Bluetooth exactly right? How many people buy cars based on the speed with which Bluetooth connects?

As evidence, sticking with a single vendor means I don't have weird stuff happen, and can in fact connect multiple pairs of AirPods to a single Apple TV unit so my partner and I can watch together in outward silence.

I still cannot, as far as I know, connect a single pair of AirPods to more than one device, but that doesn't seem like a feature anybody would have considered when initial developing the BlueTooth spec. Perhaps such a feature will come soon, at least with a single vendor solution like Apple's.

As for multiple headsets to one device, a lot of devices have challenges playing a certain audio stream to multiple output devices. For instance, my laptop has a speaker and my monitor has a speaker. There's no default way in Windows to play the same audio out on both of these outputs. I would need software to emulate a sound device and end up duplicating the stream to both other sound devices to target both outputs at once. Its been a while but I think that's also true on MacOS, its true for the defaults of a lot of Linux distros, its true on Android. You might have issues outputting to multiple headsets depending on your chipset, but the first level limitation is really more on the operating system side of things.

As for "can't connect multiple devices to one headset", as mentioned by others you can do this if you get the right hardware. I have a few headsets which support multipoint.

Why did Betamax lose out to VHS? Why did MiniDisc never take off? Why does the internet still rely on JavaScript?

From my sideline perspective it's probably because Bluetooth was developed without knowing how successful and expansive its use would become. It was developed by mobile phone companies to connect wireless earpieces to mobile telephones, and that was it. The entire scope of the product that is Bluetooth. They didn't even expect it to be used for stereo (or more channels) audio, _just_ for telephony ear pieces.

It has since been used for many things that it just wasn't engineered to do.

However, it _is_ (or rather has become) a rather ubiquitous protocol through lack of alternatives, and now is the must-use option for any hardware vendors wanting to connect to nearby devices. Pragmatism/apathy.

For audio devices like speakers or headphones I've thought about an idea for playing music at least. You could have the host device send the playback device the files and the playback device would play the file locally and it would be synchronized with some sort of a timestamping routine between the host and the playback device. There wouldn't be any need to transfer data in real time in high bandwidth between them so you could have lossless audio. Being able to play back a majority of audio codecs shouldn't be all that hard or license encumbered. Even if you take a shortcut method and just transcode everything on the fly to flac. You maybe only need to store the current song that you're playing back. Heck you could extend this so it doesn't need to be built into the headphones or the speakers as a protocol and it could just be like one of those portable Bluetooth things that you can buy that you could plug any audio device in except it uses this new thing.

But the touch on all of the things that you brought up in your original post related to like real time audio. I swear there are implementations where multiple headsets on one device or multiple devices to one headset do exist. I don't think the problem has much to do with Bluetooth as a standard even though the standard is extremely complicated I think it all has to do with software and implementation on the part of the host device like the computer or the phone and the playback device. Like if there was a standard reference device example for both of these things that did everything correctly I'm pretty sure all of the things that you brought up work. Although I would like to be corrected on this.

We do have something better! And we’ve had it for decades.

It’s a cable.

Have you ever bought a product because "the Bluetooth integration is so good?"

I'm sure a few people have. But it's not like you choose a car or phone because of it.

Are any of these problems actually Bluetooth problems? It seems the data protocol works just fine. It appears to me that the various devices just handle the associated tasks poorly. Eg you could take a call on your phone while playing music on your computer, if your phone had the functionality to send the music via Bluetooth and keep the phone conversation separate.

We don't have anything better because radio silicon is a terrible industry to be in. The amount of institutional knowledge and capital required is insane, and the network effects on the protocol are massive.

The flip side is that consumer electronics manufacturers are horrendously cheap when it comes to BOM cost. If your component doesn't directly provide a feature list item consumers will recognize, it's not going in the device. Similarly, consumers don't care about radio protocols that aren't universal. This leads to a chicken and egg problem where manufacturers won't introduce new things, and when they do consumers won't use new things because new things don't stick around.

As for why BT sucks, it's a combination of very few chipset manufacturers (at one point it was basically just Broadcom and CSR, now both part of Qualcomm) that suck at software owning the entire market, legacy protocol design decisions constraining future capabilities (this is why audio sucks), and simply being too complicated.

it’s just so device-specific. My JBL speaker, aftershokz bone conducting headphones, and iPhone all play nicely and I don’t have any problems. My Windows machines consistently have problems with bluetooth, but poor quality is a standard of the Windows experience so it doesn’t surprise me. My Sony stereo receiver is always a nightmare to pair.

Honestly the JBL Charge speaker has the best and simplest solution to this: it just lets two devices pair to it simultaneously.

The Bluetooth Special Interest Group (SIG) is responsible for publishing all the Bluetooth specs and you can download them here: https://www.bluetooth.com/specifications/specs/

Notice that everything appears to be there: very detailed specs and information about testing. However, when you try to implement one of these specs you quickly realize that you cannot do it with the spec alone. You need example code, base implementations, test suite software and test data to build conformant software. Unfortunately, the Bluetooth SIG hides these resources behind a membership wall. Guess what happens then? You get lots of implementations of these specs that are a little bit off and don't handle all edge cases.

If I were to wave a magic wand I would like to see Bluetooth SIG change to a donation based financial model and for them to make all resources freely available. Right now they make money from branding, certification and country club membership fees. No wonder the ecosystem is one big tire fire.

There is an xkcd for this

https://xkcd.com/927/

Only some of the issues you list are inherent to Bluetooth. Others are a result of trying to balance doing the right thing for the 80% case which results in sub optimal experiences for edge cases. I don't see a lot of evidence that just coming up with a new standard would address many of these.

The main issue with Bluetooth is the sound quality sucks. That is actually due to the Bluetooth standard.

Yeah, the bluetooth in my car is so hopelessly pathological that I always turn off the bluetooth in my phone and turn the internal phone speakers up if I want to use the maps app. If I don't, first it will immediately pick some song at random on my phone and play it at full volume without my asking. If the radio is turned off, it will still connect to the phone, which disables the phone speakers, but then it will not make any sound at all. Or it will connect up but will turn the volume all the way down which also results in no sound. Sometimes it will randomly connect to various devices in the car. Sometimes if you plug in the phone to recharge but leave the bluetooth on it will turn off the phone speakers but also not make any sound from the car speakers. It's bad. The whole system is actively hostile to the user.

1. It's basically good enough, despite its problems.

2. It has brand-name recognition.

3. People who need it know that its the "wireless thing" for audio and music, often without their being able to articulate precisely what it does.

4. It's baked into enough hardware that a competing technology would struggle to enter the market.

I'd been using BT for the past decade as a wireless receiver for audio or mouse/KB.

It's only very recently that I discovered that you could use it to transmit files from Device A to Device B. No middleman app or cloud sync service needed! Considering how awful USB file sync is between Mac OS and Android, I don't even break out the cable to transfer files anymore.

The downside is that transmission speeds are very slow, approx. 5 seconds to transfer 1 MB. That's fine for EPUBs and text-heavy PDFs, but not for anything bigger.

I abandoned bluetooth early on, because I kept having issues. Stubborn pairing is still a pain.

For music, I bought a DLNA renderer (more like a Chromecast), and just assumed that lots of software could remotely talk to it. But about the only software that almost works with it is something with a poor UI from yesteryear on Android. And music service support is hit and miss. So I'm edging towards Bluetooth now.

That said, yesterday I resorted to CDs. And today, I've jacked a spare phone into an auxiliary port. And I won't use my phone for Bluetooth music mainly because if I walk out the room or want to take a call it all goes tits up.

I've had Bluetooth on Debian Linux on my Thinkpad for years, and different releases have been hit and miss for things like file transfer. And address book syncing. And that's not confined to Linux either.

When it works... It does feel like magic.

Really I want to easily route sound from one app to a particular device or devices with easy remote management. Voice control is a bit hit and miss. But hands free remote is a good idea.

UI is very esoteric, like when you are offered a list of Bluetooth services. A phone I had would offer itself as a remote device or something, but I never figured out how and what it did. Or the worry that your phone might turn into a data access point accidentally.

For what it does, Bluetooth works fine in my opinion. We expect Bluetooth to work like magic and to follow all the standards but we also expect it to work around issues we have with the standard (codecs, interference, etc.) because we don't want a bad experience. You can't have both!

If you stick to the stuff that works with every device (no automated switching, no proprietary codecs, no out of spec bandwidth and timing requirements) Bluetooth works quite well in my experience. Only when companies try to invent their own solution or very cheap, crappy, standards avoiding devices get involved does Bluetooth really start to break down.

Another issue is driver stability. I swear to god, Windows just hates Bluetooth. Somehow, Windows drivers for even common chipsets are worse than Linux drivers. On the other hand, on some Linux kernels, having Bluetooth on while putting a device in sleep can cause a kernel panic... It's all so unstable. There's nothing in the spec that says your software must hang and become unresponsive when an (un)pairing attempt fails, but here we are!

As for some of your complaints:

- connecting devices will make them behave like they were made to do. If they play default music, that sounds like a product feature that's off, not a protocol problem.

- pairing multiple devices is not governed by the spec (nor should it be, in my opinion). What a device will do depends on what makes sense for a device; a party speaker may want to connect to whatever device is available, but headphones or a keyboard prefer connecting to the device they were last connected to. Again, this is more of a device implementation feature, not really a protocol thing.

- connecting multiple headsets to a device is possible. In fact, I've done so in the past. You're limited by the throughput of your Bluetooth version (quite high, these days!) and any interference, but there's nothing preventing a device from playing to two devices at once. In Linux you can create a dummy device to stream to multiple audio endpoints through some config or command lines; on other platforms you'll need custom applications. This is an OS design issue, not a protocol issue, and it's no different from playing audio to both your TV and your headphones (quite useful for watching movies together with people with hearing aids and the like!)

- Can't connect multiple devices to one headset: this is a protocol issue. Devices join a piconet which needs to be synchronised and is controlled by a single master device. In theory that master device could be your headphones, with both other devices acting as clients, but in practice this is often not the case. Such a system can be quite finicky to work with when one or both devices go out of range or if multiple devices try to send high definition audio over the same channel at the same time.

Like all things Bluetooth, I've often wondered why WiFi Direct hasn't been more of a success. It'll eat more power, but it solves so many issues with Bluetooth, especially with modern 5.2GHz WiFi. For battery life purposes we'll be stuck with Bluetooth for a while, but I'd like to see WiFi Direct get a second chance for sharing files. Hell, it could even work as a cross platform Airdrop alternative (though Apple will obviously never join in).

Another way to look at it is that BT is such a successful technology that it lowered the barrier to entry for a lot of devices that would simply not exist was it not for BT. It means that with any technology we would have the same problems, lots of cheaply made devices with half ass implementation.

You know, I think if you look in the home automation space you'll see a lot of interesting protocols in the works. Zigbee, Z-Wave, Thread, and Matter. I think people are working on this problem for the IOT space. Bluetooth is really a strong easy to support protocol and BLE is also an amazing feat when it comes to battery life. Terribly boring to reverse engineer though. I think you also see it more because phones support it by default.

I think a lot of the time it can be devices that implement the protocols poorly because I share your pain with my airpods max. However, I have a pair of a bluetooth headphones that have been amazing for 5 years.

I'm pretty sure Apple got some tweaks put into the Bluetooth chips they use to help out with some of the connection reliability issues. Put in at the bare metal level before the stack so as to avoid breaking the "standard".

Apple has also used out-of-band pairing mechanisms to enhance the customer experience. But again, there is only so much they can do.

There are many problems built into the standard and so there was only so much they could do.

Ironically, the standard itself is preventing better experiences.

It's been over 10 years now since BLE came out. Many companies have crashed and burned or abandoned products or just accepted poor user experiences in those 10 years.

The Bluetooth SIG is a monstrosity. I bet you would have to break off to fix the problems in under 10 years. And the SIG would probably sue to prevent that.

Multiple reasons (as outlined partially by others):

  - It is incredibly hard to make something so versatile work well everywhere, all the time, for everything
  - It is even harder to get multiple stakeholders to do this consistently
  - And it harder still to do this if the business case doesn't allow for (long-term) support

This is mostly a business problem and not really a technical problem. Wi-Fi is similarly pretty badly implemented, for similar reasons, but the upside is that it doesn't have a billion specialised profiles, it generally just has to pretend it's encapsulating network frames the same way ethernet does. As long as it can do that, people can make use of it.

Honestly, the latency is the biggest problem for me.

I've got a bluetooth game controller and headset for my phone (Pixel 4a), but the latency makes using them both at once impossible. If I switch to a wired headset the controller bluetooth gets better and the game becomes playable.