Audio over Bluetooth: most detailed information about profiles and codecs (2019)
habr.com
habr.com
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.
Alongside god and the manufacturer, I now know to curse the standards body too whenever trying to connect these damn headphones!
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.
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.
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.
Much like ASICS are a big step up in performanceand energy efficiency for crypto mining, they are in this application as well.
> Surprisingly, Bluetooth devices require nearly three times as much energy to transmit a bit of data at the physical layer than WiFi devices.
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.
Much like ASICS are a big step up in performanceand energy efficiency for crypto mining, they are in this application as well.
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.
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.
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.
If so, How?
As for recreating the audio, you'd have to deal with capturing the key exchange handshake and cracking it.
Whether the encryption is implemented correctly and on (with strong enough keys) by default on most devices is another question of course.
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.
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.
Only hardware is BT SIG certified I believe, not userspace software.
I really wish wifi had some standards for this sort of stuff too.
[1] https://www.bluetooth.com/bluetooth-resources/introducing-bl...
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