The thing that gets me about bluetooth is how nonsensical the conflict resolution is. Like, if I'm playing something through a bluetooth speaker, and my wife wanders into range while listening to a podcast on her phone, it will automatically connect to the speaker and boot me off. How does it make sense to auto-connect when another device is already using the speaker? Similarly, I'll be listening to my bluetooth headphones, and my wife starts her car in the garage below me—suddenly my phone disconnects from the headphones and connects to the car instead. If I'm already playing through one bluetooth device, I probably don't want to automatically switch to a different one - especially one with a far weaker signal/likely farther away.
I get that these aren't trivial problems to solve, but they certainly seem possible to improve on, given the maturity of bluetooth at this point. Also perhaps they aren't the fault of the protocol at all, but just the choices made in programming phone OS's. Regardless, it's annoying!
My guess is it's actually part of the managing software.
Specifically I guess this because this is what my Airpods do. They don't switch 'players' if I'm actively listening to something, but if I'm not, whatever 'boots' last is the one who gets to become my Airpod's player.
The fact that we have different experiences tends me to think it's a higher layer that's doing the 'auto switching' and someone made too simplistic of an auto-switcher?
My opinion on this is that These problems are actually trivial to solve. The problem with firmware is that it almost always lacks polish. It is shipped as soon as it works at a basic level.
Yes, constantly. For instance I wander around the house listening to an audiobook on bluetooth headphones, walk into a weak signal zone, and the audiobook stops, and I hear in the bedroom that the bluetooth speaker next to the bed has mysteriously started to play a youtube video from my phone. So a momentary loss of signal causes the software to change both input and output. This is with a Samsung S9+.
Sounds like you need to get better hardware friend. I would say the firmware on those devices is the cause of the issue. The phone is going to broadcast a connect packet to a device it knows, it's the devices job to let it connect or not. My edifier and sony bt speakers stick to one connection until it is disconnected.
That's entirely possible. This has been the case on every device I've owned, but those have mostly been Samsung phones (currently a Galaxy S20), so maybe Samsung is just bad at this.
No, it definitely isn't. Why is audio quality so much worse when I connect my headphones as headset instead of as audio-sink (even when I'm not speaking). Why is it so hard to connect two audio sinks to one source? Why is the experience of using the same sink on multiple devices still not smooth?
I also don't get why this was not fixed yet. There is clearly the need for high quality Bluetooth headsets.
Two sinks to one source works well for some devices. But this is more an edge case for most people.
I also have the feeling, that Apple AirPods have a better quality if you connect them to an iPhone, then any other Bluetooth headsets. Do they use a proprietary Handsfree profile?
My understanding is that music gets decompressed on the Apple headphones, the original AAC stream is sent over the wire. Most Bluetooth headphones will just effectively transcode the audio, such that for example AAC gets decompressed then recompressed into AptX/LDAC. For music listening, it's completely suboptimal. I use FLAC sources for my Sony headphones which makes them very listenable (along with copious EQ to tame the +5db excess bass). Bluetooth headphones have a lot of room for improvement.
> My understanding is that music gets decompressed on the Apple headphones, the original AAC stream is sent over the wire.
That's claimed at many places, but this one claims the opposite: https://habr.com/en/post/456182/, that everything gets (re-)compressed into AAC on the sending device before sending it to the Airpods, in order to mux other audio events. In principle, with end-to-end Apple hardware, they could send multiple streams and leave the muxing to the Airpods, but I don't think anyone has conclusively shown if this is actually done.
If there's one thing I've learned about technical claims about Apple hardware, it's that they are not to be believed unless they come straight from Apple in a precise and unambiguous statement, or from a reverse engineer/hacker who has looked at the code/protocols.
The reality distortion field is just as strong as always when it comes to technical details too. People will make random things up to prove that Apple is different or (more) special.
Claims of poor Bluetooth audio quality generally fall into the following categories:
* Bad source settings/implementation (i.e. bitrate too low)
* Bad sink implementation/EQ/DAC
* The HSP issue referenced by OP (where you can't have both HQ audio and use the mic)
* FUD by patented codec authors
The reality is that even the basic royalty free Bluetooth SBC codec is perfectly fine, and sounds transparent at high bitrate settings, which decent sources should be using and all sinks are required to support. Transcoding doesn't make much of a difference either. It's a poor codec, but the bitrate is high enough that it doesn't matter. You can ABX test it yourself if you're so inclined, purely in software, with high quality wired audio hardware. I have. You'll see the codec isn't the problem.
So when your Bluetooth device sounds better wired than wireless, or works better with AptX or some other patented nonsense codec - most likely the problem is careless software/firmware (or outright crippling to push patent licenses), not the spec being bad.
(I say this as someone who was gotten into flamewars over the quality of ffmpeg's AAC implementation and found bugs in the Opus reference encoder; I can tell when audio quality drops)
My personal lived, yet anecdotal experience is with a fairly decent Kenwood head unit in my car. I'll often use bluetooth for convenience but from time to time I'll connect over USB. Whenever I make the direct USB connection the sound quality is always noticeably better: rounder deeper sounds, much better quiet and loud sounds ...
This leads me to conclude that one or other of the following must be the case:
- The iphone DAC is x10^9s better than the Kenwood DAC
- Kenwood and iPhone have negotiated a poor codec
> most likely the problem is careless software/firmware
So, don't take this wrong, but I'm going to wince and say this has a shade of a no true scotsman argument to it ... and I say this because I think that this is crux of what's wrong with Bluetooth. It is a very closed technology, and it's very hard to get a leg-up on the standardisation or how to use it for your own devices if you want to do anything any way commercial.
I'm saying this as a Telecomms guy, who is used to having high quality standards documentation, and reference implementations for just about everything I do. Interoperability is key. Though Bluetooth is a communications standard, it seems to have been influenced more by consumer electronics than comms.
After 10-15 years or so of using Bluetooth, it increasingly feels like a technology not really developed in good faith. You get these clunky imprecise results that I and other people report all the time. Working with a bluetooth device you're always going to be throwing the dice vs the certainty of plain old wired connections. It's plain to see that right across the industry people are hedging against it, and anybody that does require reliable M2M short-wave radio is using a proprietary protocol.
Bluetooth is a millstone around our necks. Yes it gives you freedom from wires and a certain limited amount of interoperability, but you don't get a huge amount that you wouldn't have got vs proprietary radio technologies.
I'm not saying Bluetooth audio doesn't suck in practice. I'm saying it's not the codec/technology's fault, but everyone assumes it is, and that is exactly what all the companies peddling patented alternate codecs want you to think.
I have a set of Bluetooth speakers, and they sound better over the wired aux in than wireless. I know what this experience is like, and this is why I have tested the codec myself and concluded that it wasn't the problem. And since Bluetooth is a digital audio standard, if the codec isn't the problem and the data is arriving at the destination, then clearly any quality problem is the destination's fault.
Don't get me wrong, Bluetooth is a horrible standard for many other reasons (it's worse than USB, and that's saying something); I've implemented Bluetooth-related protocols. But "screws up audio quality" isn't one of them.
I’m saying that it’s so vulnerable to codecs, “is” the flaw with Bluetooth. I’m happy you found a combination that works for you ... but what is the point of Bluetooth exactly if you can’t have good interoperability.
In fact, I wouldn’t be surprised if this issue was created just so there could be a “marketplace” for codec pedlars ...
> Transcoding doesn't make much of a difference either.
I respectfully disagree. Transcoding does make an audible difference, at the bitrates typically used, and should have no place in "high fidelity" audio. My issue with these Bluetooth codecs is that they are not used at the sources and so will always be used in practice for transcoding.
Have you ABX tested an SBC transcode at the maximum bitpool settings vs the original? Because I have, and I couldn't tell the difference.
The "transcoding is bad" story is about low quality settings, archival, and/or bad encoders. E.g. don't do repeated transcodes with the ffmpeg AAC encoder, not even at 320kbps. But one final transcode with SBC for over-the-air delivery at the max allowed bitrate? That's totally fine, especially for typical Bluetooth use cases (listening on the go, casual headphones, etc).
Well, I have noticed significant degradation of 128kbps MP3 sources when sent over Bluetooth, whereas my FLAC CD rips sound fine. I don't think that the effects of transcoding are well understood or well-studied, especially the interaction between different codecs.
And why does latency compensation still not work properly? For real time stuff like games or video chat it's tough to compensate for latency, but when watching a prerecorded video there's no excuse. Video and audio should never be out of sync, and yet I find they usually still are.
I have zero interest in using my wireless headphones as a headset, ever. And yet, software will randomly manage to trigger it and kick me off of the A2DP profile.
Microsoft Teams is the worst at this. It completely ignores my system audio preferences (which were painstakingly configured to use the expensive microphone as an input, not the wireless headphones) and tries to use the headphones, which switches the profile to headset and ruins the audio quality for the remainder of the call.
I guess because it switches to a mode that favors latency over sound quality?
I tried using bluetooth headphones on a digital drumkit once, which went about as well as you'd expect. (mind you there was a laptop in between as well)
It somehow works with dedicated USB dongles that are size of a penny. Look at Jabra Evolve 65T. From my perspective as a customer it's an issue with Bluetooth standard, not hardware.
The latency problems are somehow solved when using USB adapters, so why can't we embed those adapters in our devices?
The fact that high quality simultaneous audio input/output isn't possible is a big negative for BT that I just can't believe hasn't been addressed yet.
Headset voice has to squeeze over GSM voice channel, that is 9.6kbps.
I had pretty smooth experience with using Pulse with multiple sinks/sources, maybe look into doc. Only problem I had was latency sync while multiple sinks play together.
The fascinating thing about this thread is its contrast to other technical discussions on HN.
A website is broken? Somebody digs up which stack it's running, suggests a config change and the discussion evolves around that. Some Rust thing is weird? People discuss fixes, patterns, some code example. Fabrice Bellard made a new magic thing? People celebrate with links, their experiences and cool own Show HN things.
But here? "I bought $consumer_device, it sucks" .. "Yeah I can't believe latency is still not fixed." .. "Oh man when my wife comes home $weird_device connects to her car". That's how my aunts discuss technology. Guys, this is Hacker News, why is the deepest we are actually talking hacking here just the mention of different bluetooth profiles?
Is this a sign of how closed and proprietary all bluetooth stacks are so that even technically skilled people can only conclude that it sucks and move on? Otherwise I'd have expected people to already have suggestions for fixes. This is a very sad state of affairs..
I think so, yes. Compare this with IEEE and GSM stuff. Something has gone on with the Bluetooth process that makes it seemingly impossible to break out of the proprietary space.
While I agree that Bluetooth enables a lot of relevant use-cases with an open standard, I still see room for improvement:
- I still hate that the listening experience degrades as soon as I want to use a microphone simultaneously
- connecting multiple headphones with a single source is not as easy as it should be. Just this week I bought an extra device for this use case (1 Bluetooth source to 3 Bluetooth consumers), but is has annoying latency, sync and pairing issues.
- using the same headphones with different sources is a mess. I constantly have to enable and disable Bluetooth on various devices, so that they don't connect automatically to the wrong source. For example my Sennheiser Headphones can connect to two sources, but play only one at a time. So when you watch a movie at your PC and someone sends you a message on your phone, it can happen that the headphones don't return to the PC audio after playing the notification sound from the phone.
I connected two Sennheiser HD350BT headphones to one BT Transmitter. That’s a TaoTronics. I was impressed that it worked. But you are right - with multiple devices connected latency becomes a compromise.
I agree with the core thrust of the article, but there are still major shortcomings that are frustrating. Why isn't it possible for my headphones to connect to my phone and computer at the same time. Having to change the connection 100 times a day is so annoying.
But they are certainly leagues better than they used to be. Connections reconnect seamlessly and usually turning on a device is sufficient to get it to reconnect to the thing it was connected to and the UI of various applications has advanced to make things like switching from the headphones to another output much easier.
> Why isn't it possible for my headphones to connect to my phone and computer at the same time. Having to change the connection 100 times a day is so annoying.
Some headphones do that just fine - as far as I know it’s a choice the manufacturer makes. I’ve had cheap Jabra and Jaybird headphones which support multipoint. My much more expensive Sony’s do not and it infuriates me.
Really? That's amazing! I have Beats and all Apple gear, so I expected that it would work if it were possible, since Apple controls the entire lineup. Hopefully a future version will.
I still find the audio latency unbearable. Yes, most video players do latency compensation, but it often gets out of sync when you switch between wired and wireless output. And for any type of interactive audio, like games and music software, you can’t really do anything about it.
For example, if the iPhone goes portless next year, what will happen to apps like Garageband?
My smart watch wreaks havoc in every 2Ghz router home I enter.
Sending a single byte of data on WiFi via TCP/UDP? Create socket, call a function to send data. Bluetooth? inhales okay, first of all we need to know what operating system you're on. Then we need to know what stack.. Oh you're on Android and using the ndk? There's a stack but we may remove it at any time. How about some FFI to java land to use our bloated wrappers with managers, personalities, and all that other good stuff? Oh you want it to work on Apple too.. And on Windows you need to choose among multiple stacks, which you may have to install yourself, if you want THAT device to work. Or THAT feature. And then things just don't work reliably. Gotta re-pair (no pun intended). Gotta increase buffer sizes to megabytes.
It's just such a mess. Just go WiFi direct or cable.
The most baffling thing to me about Bluetooth and I guess WiFi as well is that both disrupt each other when WiFi is on 2.4 GHz band. I wonder how creators did not see this blunder beforehand.
I know the solution is to use 5GHz for WiFi but my dad has to take online tuition from a floor above me where there is hardly any 5GHz coverage and he can't reliably connect to other band because I need to take my calls over Bluetooth headphones during same time. Now either I have to deploy another router on top floor or need to buy wired headset or continue taking calls from room on the other corner of the house where there is hardly any WiFi coverage.
It's not that they didn't realise they were on the same frequency - it's that 2.4Ghz was really the only suitable unlicensed ISM band available. There's other devices there too - 2.4Ghz DECT phones for example when landlines were still a thing, 2.4Ghz video doorbells etc.
The solution is to wire everything and leave the wireless for the low bandwidth signalling application and just a few heavy users. Once you And your neighbours have a managerie of wireless devices there’s just no way to manage what happens with Um.
Yesterday I checked around how I could contribute to the bluez stack. The communication seems to be at #bluez on freenode, but I didn't jump in yet. I don't know the ethics here and there were no messages in the channel. I think contributions on this level will in the end impact the most people. Anyone wants to join as well? I was planning on first describing (for myself or online) the last bug fixes and contributions to get a feeling for the code.
This is actually a great step forward for science, we finally found the elusive Device-Pair That Works With Bluetooth.
What will be next, the Graviton? Dark matter particles?
I think that's a second recent discussion on Bluetooth here that doesn't mention aptX at all. For me that was a gamechanger, wouldn't really buy anything that doesn't support it. Unless there are some other similar things around which I'm not aware of.
AptX is lossy compression which when applied to already compressed sources (e.g. Spotify), still gives noticeably inferior audio (it's effectively transcoding).
Most people listen to compressed music and so the right thing to do with limited bandwidth is to send the original compressed data over Bluetooth (as Apple/Bose do with AAC). AptX is probably fine if you have non-lossy compressed sources like FLAC.
Well I hope that Spotify on Android does send original AAC to devices which support it too, but more general point is that you need support on both sides. Something has to decode that AAC on the receiving end, otherwise you'll get standard codecs which are crap (or rather their implementations).
People discuss it without those terms and come to different conclusions, e.g. most like when you use a mic you switch codecs, 99% sure.
The article is completely anecdotical. Just like how I struggle daily with devices which can seemingly only remember a singe pairing and need to be re-paired constantly.
Does anybody know how to get high-quality two-way Bluetooth audio on Linux (e.g. for video chat)? It works on Android, Windows, MacOS, iOS. Just not Linux.
It doesn't work on macOS. At least not with standard Bluetooth headphones. The only Bluetooth headsets that support high quality and duplex at the same time use proprietary extensions to do it, and those extensions tend to only work on one platform.
For music, which doesn't require a securely negotiated connection, I'd prefer a bag of small, cheap FM transmitter/receiver devices with a simple frequency selector. You could have limitless(?) FM receivers tuned to the same transmitter. Imagine adding 20 discreet powered speakers to your living room, being able to place them anywhere you like... a woofer in each corner, a full-range unit on the coffee table, two floor standers playing left and right channel respectively, and a bunch of smaller speakers dotted around the kitchen, bathroom etc. The only hassle would be 'changing the channel', but you would work that out I'm sure. Each room could get its own frequency, and each member of the household could get their own personal frequency. you could revive your old Sony AM/FM Walkman...
Edit: So I just searched, and such a thing exists. Not the crappy in-car things that insist on cigarette lighter power supply, but a wearable device (aimed primarily at tour guides). For under £200 you can get a Retekess FT11 transmitter and 10x V112 receivers. Tempting...
Yes and no. We're finally able to get it to work somehow, but nowhere near as smooth and reliably as cables used to work before.
For instance: In my car I have to turn BT audio on and off around 3 times before it manages to establish a link between my phone and my car and can play music. And only I am able to do this. My wife has long given up.
You know how she manages if I give her a cable? She inserts the cable and it just works, because that's what cables do.
Bluetooth has miles to go before it reaches the same kind of user friendliness and reliability.
I feel your pain. I have NEVER had a phone that quickly and easily pairs with our car stereos. I'm pretty sure it's because I use android phones. I'm convinced the manufacturers test with iphones and say "yep, works perfect" and call it a day.
In one car, we have an aftermarket JBL stereo; it typically takes about 30-45 seconds to pair. Unacceptable, but better than the stereo in the CX-9 -- with that one, it's typically about 3-4 minutes before I can hear any audio. 30 seconds of searching for the phone, and then like 2-3 minutes of limbo where it's doing god-knows-what telling me it can't play audio while it transfers phone data. Surely my contact list doesn't take that long to sync?
Quite often, I get a "ghost" connection, where the phone indicates it's connnected, and the car stereo does, too. Audio applications are playing, and the time is advancing, but no audio is coming out. Usually takes about 2-3 disconnect/reconnect cycles to correct it.
Paired to an Amazon Echo, my phone disconnects every time the music pauses; this is a new problem.
For a while, my Sony STR-DN1050 connected so well that I could just select it on my phone, and it would power up the receiver, select the Bluetooth input, and connect within 3 seconds. Then one day, it just stopped working that way, and I have to power up the receiver and manually select the Bluetooth input before trying to connect.
About once every couple of months, I have to REBOOT the phone in order to get pairing to work.
I've seen this erratic and pitiful performance on a wide variety of android phones, from low-end to high end: Galaxy S3, Galaxy S4, Galaxy S8, Pixel 3, Pixel 4, Moto G6, Moto G7. Over nearly a decade, it just never gets better.
My boise headphones start getting jittery audio when I’m more than two feet from my macbook.
My car will pre-empt every other audio device, and the sound is crap until I plug it into the USB port.
I can’t keep peripherals reliably connected when they sit less than 3’ away from my macbook.
Switching devices between sources is an absolute nightmare of overloaded switches and counting in my head. Two seconds to power off. Two taps to fast forward. Hold for volume up (but not longer than two seconds!). Five seconds for pairing mode. Aaaarrrgh.
My 2018 Mac mini BT is woeful when I have a usb3 hub connected due to interference.
I installed a Hideez BT dongle. It works, until reboot, at which time I have to go through reconfiguration all over again. It would be impossible if I didn’t have cord connected peripherals for bootstrapping.
Apart from all that futzing, I think Bluetooth is useful. I particularly like talking on BT intercom with my motorcycle buddies. Who woulda thought the range would exceed 1km?
This should be titled "I finally think Bluetooth is OK".
- The Airpods came out in 2016 and did away completely with connectivity issues
- Same for the Sony WH-1000, I've been using it for years and don't remember it dropping a connection
- Ditto for a Jawbone Jambox speaker from 2015
That said, Bluetooth still kinda sucks. The in-ear version of the Sony has connection drops. Connecting to multiple devices is a pain. It's still basically impossible to transfer a file to your computer, or between devices (I gave up on that about 10 years ago). Latency is terrible, both for audio and keyboards or mice.
>The Airpods came out in 2016 and did away completely with connectivity issues
My Airpods disconnect about every 10 or 15 minutes when I'm outdoors. Then after reconnecting, some of the tap functionality stops working until I take them out of the ear and put them back in again.
yeah, however a new macbook is unable to maintain the bluetooth connection with a soundbar depending on what cables or dongles have you plugged in. the frustration on such cases is so big I’m grateful the hammer is on the parking storage room and not on a handy place.
I get that these aren't trivial problems to solve, but they certainly seem possible to improve on, given the maturity of bluetooth at this point. Also perhaps they aren't the fault of the protocol at all, but just the choices made in programming phone OS's. Regardless, it's annoying!