Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login
Audio over Bluetooth: most detailed information about profiles and codecs (2019) (habr.com) similar stories update story
68 points by schaum | karma 193 | avg karma 2.88 2021-03-06 10:37:16 | hide | past | favorite | 37 comments



view as:

Might be a lame question, but can BlueTooth connections be intercepted and "heard" ?

If so, How?


You just get some hardware that can monitor the traffic like greatscottgadget's ubertooth one.

As for recreating the audio, you'd have to deal with capturing the key exchange handshake and cracking it.


Bluetooth supports solid encryption once paired, but the pairing is usually unauthenticated and thus subject to man-in-the-middle attacks.

Whether the encryption is implemented correctly and on (with strong enough keys) by default on most devices is another question of course.


Bluetooth has the Secure Simple Pairing (SSP) feature, and Bluetooth Low Energy has the LE Secure Connections feature, which both use Elliptic Curve Diffie-Hellman Key Exchange and therefore is protected against passive eavesdropping. The standard also includes the ability to support authenticated pairing for protection against Man-in-the-Middle attacks; if you've ever had to see if a 6-digit number matches on the two devices that are being paired, then you are seeing the authenticated pairing taking place.

Even though the Bluetooth standard includes these features, many products don't actually use them and simply transmit data without any encryption or authentication procedure. This is particularly a problem with many Bluetooth LE products.


Can't we just replace this standard by WiFi? That would be one less standard to deal with. And much better bandwidth.

Too much power for small devices like earbuds or iot devices.

That depends on how long you want to use them. For some the trade-off against sound quality, features and user-friendliness might be favorable.

the shield tv's controller (2015) was wifi based, & could transit audio. it's not tiny, but it shows wifi was viable for a latency-sensitive battery-powered system five years ago. for many headsets i'd think it would be quite doable but yes i'm not sure we've scaled wifi down to earbud sized devices. and yes power consumption is afaik higher.

it feels mainly like an adoption / standardization problem. we have chromecast speakers galore & wow is it nice having devices available over the network. alas there's no standardizations, no cooperation, no system for wifi to be useful. other than the very limited controlled & closed ones.


That controller had a 2600 mah battery for ~60 hours of operation. Much larger in power capacity and volume than what is suitable for tiny earbud like devices. https://batteriesglobal.com/products/nvidia-shield-battery?v...

Ok so 260 mah for 6 hours? Using some 5 year not-that-fancy-at-the-time old technology (Ozmo2000)? That does far far far far more than send audio? That is much lower-latency than what we'd need to compete with Bluetooth (which radically increases wireless power needs)? For comparison, Google Buds are 120 mah & 5 hours. All we need is a 2x improvement in power, for a far less complex device, & we've had 5 years? You are making the case for me my man. This sounds more doable than I thought!!

Miniaturization is indeed a challenge. Who does make really small wifi units? Who do they sell to? How much smaller do they need to be? I suspect it's simply never been a goal. And why would it be? There's no protocols that make wifi even potentially compatible with these sort of consumer device systems, no matter the size! Even with what we have today though, a wifi microphone or wifi gaming headset should be easily possible, no challenge at all, and could have far better quality & likely latency than what we expect from bluetooth. And I rather believe we could make smaller wifi if we had an interest in doing so. We are limited by our imaginations, our imaginations and our lack of standards/will.


Not for specific applications like bluetooth headsets. There are application specific ICs that are made for the specific https://www.microchip.com/en-us/products/wireless-connectivi...

Much like ASICS are a big step up in performanceand energy efficiency for crypto mining, they are in this application as well.



That's interesting.

> Surprisingly, Bluetooth devices require nearly three times as much energy to transmit a bit of data at the physical layer than WiFi devices.


I imagine that power consumption is proportional to amount of data and inversely proportional to latency and data rate. To minimize latency, the transmitting device needs to send smaller packets more often, leading to poor efficiency due to overhead. The faster each packet can be sent, though, the less time the transmitter needs to be powered on.

I suspect that the only difference in power consumption would be due to the modulations that wifi uses vs. bluetooth, i.e. wifi is able to cram more bits into the same amount of RF energy.

The tricky bit with radio comms is that you absolutely have to be able to cope with data loss. The easiest, lowest latency way is to just encode the data in a way that allows it to degrade gracefully. The listener is aware of the data loss, but isn't bothered by it. This implies that there's a lot of redundant information in the data. That is at odds with compression, though, because compression is all about removing redundant information; a loss of any bit of data results in severe degradation. Radio links that send compressed streams of data need to either rely on acknowledgements with retransmission on data loss, or they need to add just enough redundant information for the receiver to reconstruct the original data stream even after expected packet loss. The algorithms that provide that "forward error correction" work by distributing redundant information across multiple packets, which inherently adds latency since the receiver needs multiple packets to decode (or recreate) the payload of single packets.


Not for specific applications like bluetooth headsets. There are application specific ICs that are made for the specific https://www.microchip.com/en-us/products/wireless-connectivi...

Much like ASICS are a big step up in performanceand energy efficiency for crypto mining, they are in this application as well.


I'm not sure I follow what you mean. Of course an ASIC can be designed to maximize the efficiency of any given RF device. I personally have a BLE enabled medical device implanted in my chest with a 10+ year battery life. Based on a neat x-ray image I have, it has a single BGA IC, half a dozen ceramic capacitors, what looks like a crystal oscillator, and a couple discrete diodes.

My point is that there's inherent energy required to transmit information via radio waves given a specific modulation and framing. Less data takes less energy than more data, and less framing takes less energy than more framing. For the same data rate (digital audio), lower latency requires more power than higher latency because there's more framing overhead. Additionally, because of how noisy the medium is, there's an inherent need for redundancy in the transmitted data, and that redundancy must either be distributed in time or in space. Distributing it in time generally requires less power but inherently adds latency. Distributing it in space means transmitting the signal with more inherent power.

That's true whether you use bluetooth or wifi and have an optimized ASIC. The difference between the two is the available modulations and framing. If wifi supports a modulation that's more inherently efficient at transmitting low latency audio data than bluetooth, then it would make sense to implement it. WiFi seemingly isn't designed to do that, though. It's designed to be good at transferring data at orders of magnitude higher data rates, using proportionately higher power. The corresponding framing is designed around that assumption.

Legacy bluetooth is terrible, but so is legacy wifi. Presumably, the latest bluetooth standards make use of modern modulations and framing techniques to minimize power consumption and latency appropriate for its use cases. If wifi were strictly better for the same use cases, then the next bluetooth standard would simply be "bluetooth" branding on top of something like wifi-direct.


"If wifi supports a modulation that's more inherently efficient at transmitting low latency audio data than bluetooth, then it would make sense to implement it."

I agree, if. In this case the if is a no. Wifi does not allow for transmitting audio more efficiently than Bluetooth. It makes sense, wifi is a much more powerful signal, takes more power to drive and process.


Would latency be comparable?

Why can't Bluetooth pair with more than one audio sink at the same time? I mean, watching a movie on a laptop with a friend is not a strange requirement, is it?

It can, it's just the non-lunux userspace cannot.

The problem is the fine synchronisation - possible to do with a lot of effort in current linux stack, but most commercial vendors just turn it off because they don't want to bother.


Why don't these vendors lose the certification then?

I think it just never been a part of it.

Only hardware is BT SIG certified I believe, not userspace software.


Bluetooth LE Sharing was announced a year ago[1], that is for broadcasting to multiple receivers. There's no (nearly no?) products for it yet. It is fairly low bitrate & has some fresh new codec specifically for it, I believe.

I really wish wifi had some standards for this sort of stuff too.

[1] https://www.bluetooth.com/bluetooth-resources/introducing-bl...


This may not be exactly what you are asking for ... but a search on Amazon for "bluetooth transmitter 2 devices" turns up several devices. I'm using it with a TV, but I don't see why the transmitter couldn't be plugged into the audio out on a laptop to send the audio to two devices.

It can with BT5.

Taotronics Bluetooth 5.0 transmitter/receiver supports two headphones.

Marketing information from Amazon

LOW DELAY: Low Latency for High-fidelity Stereo Sound, lag-free content streaming in transmitter mode. Low Latency supported Bluetooth receiver is required

MAKE IT TWO: Upgraded 2-in-1 Bluetooth V5.0 transmitter can be paired with two Bluetooth receivers (like headphones + speakers) simultaneously. Note: Low Latency does NOT support Dual Link mode


I wonder how the new Bluetooth LE Audio with the new LC3 codec would fare in this comparison.

See https://www.bluetooth.com/learn-about-bluetooth/recent-enhan...

There's on thing in the current state of bluetooth audio that actually bugs me: Once you use a microphone, the audio quality significantly degrades from the usually stereo audio quality (which is good enough for me).

I'm curious when we'll see LE Audio in broad adoption and how much of an improvement it will actually be.


It's still not clear whether LE Audio supports high quality duplex audio. They say you can use it for microphone, but that doesn't certainly means voice communication (both listening and speaking at the same time).

I have been searching in vain for a Bluetooth transmitter that can transmit from my tv to 2 Bluetooth headsets and supports Dolby surround (so that I don’t have to switch my TV to PCM every single time I switch to headphones). So frustrating

This seems like something that could be done easily in the analog domain. Most TVs have a 3.5mm or RCA line-out, line-in to bluetooth adapters are cheap, and analog signals can be fanned out with a passive splitter.

In practice, the conversion to analog and back shouldn't have any noticable effect. The bluetooth adapter is going to compress the stream anyway.

Depending on what you're hoping for, though, bluetooth might have too much latency. Media players on mobile devices and PCs are aware of the fact that they're outputting to a bluetooth audio device and compensate for it by delaying the video as well.


For a complete Bluetooth layman like myself, this was a fascinating read.

Alongside god and the manufacturer, I now know to curse the standards body too whenever trying to connect these damn headphones!


Upon coming up on sound guys article it became apparent why Apple has cut the cord. Their compression is top notch - I have experimented with various bt headsets/headphone/bt-amps. Apple AAC implementation keeps layering and detail much more compared to AptX HD counterparts - using same devices across the range.

> Unfortunately, as of 2019, the quality of voice transmission via Bluetooth is still poor, and it is not clear why Bluetooth SIG is not doing anything about it.

I would speculate there is no party with a strong interest in voice only communications participating in the Bluetooth SIG.

That's because the biggest industry group for voice only communications has its own wireless standard, DECT.

I've been trying to find a way to pair bluetooth hearing aids with a DECT landline phone but as far as I can see, no landline phone manufacturer has implemented Bluetooth Hands Free Protocol to work with hearing aids. This surprised me.

My 89 year old mother's hearing aids can pair with iPhone and Android, but she doesn't use a mobile device so I need it to pair with an ordinary DECT landline phone. I understand both landlines and old people are declining markets.

Anyway, to confirm this blank I had to peruse a lot of DECT and Bluetooth standards. Bluetooth Profile Specifications and compliance therewith are a rabbit hole, difficult to navigate because DECT phone device manufacturers don't publish capabilities.


Landlines may be declining but, in most of the world, I'm pretty sure that "old people" is a growing, largely untapped market.

To clarify, I meant old people who don't use touch screen phones.

Ah, yeah, I suspect you're right that, for a variety of reasons, tomorrow's 80-year-old is more likely to use a smartphone than today's 80-year-old.

Legal | privacy