Announcing Bluetooth LE Audio
bluetooth.com
bluetooth.com
Remember the TV's in airports running news on mute? Now just tune in your broadcast bluetooth!
Museums and art galleries don't need to provide audio guide devices - just tune into the broadcast. Might even be able to do multiple broadcasts, one for each language, for each station.
Silent discos without the need for custom headphones.
Mass transit (trains, buses, subway stations, airport) could broadcast announcements, the same way they do now over speakers, so those who have a hard time hearing the announcements (or just have headphones in anyways) could actually hear them. This would be particularly great if you could listen to your own personal audio source (ex music) AND get the BT broadcasted announcements.
And those people who drive down the street blasting loud music (err, I mean "sharing their stereos")? They'll be able to share directly to the people on the sidewalk!
(I loved your comment -- I think we both know this won't be supported).
"While technically hostile, Adbugs do not directly attack Vault Hunters. Instead, they follow their targeted Vault Hunter around and beam a semi-transparent advertisement at them, which is placed in a random position on the field of vision, obscuring part of the field of view."
You can tell when you're being attackd by an Adbug because they beam audio advertisements into your head.
By the time he rode back and shakily told us what had happened, I had no choice but to inform her at the top of my lungs (since she was 600ft down the path) that, no, it's legal if you're under 16 (in our state).
It's astonishing how bicycle riders seem to think everybody except for them is responsible for their safety.
Riding on the sidewalk is outright dangerous, I have seen multiple accidents when:
* pedestrians got hurt by bicyclists travelling at high speed riding on the sidewalk
* bicyclists go around corners and hit pedestrians
* bicyclists get hit by cars who couldn't see them at the intersection because they were riding on the sidewalk
If a cyclist and a pedestrian collide, someone might go to the hospital. If a cyclist and a car collide, someone is likely to die, and it's basically always the cyclist.
In reality, though, we all have to get along. And those concerns are addressed by cyclists not riding at breakneck speed and going blindly around corners. I don't see either of those behaviors very often in my area.
I'm amazed at how often a bicycle rider on the sidewalk will actually warn me to get out of the way. I haven't knocked anybody off of one yet. It's only a matter of time before somebody bumps into me on one and gets hurt.
https://www.amazon.com/MP3-Player-Bluetooth-Transmitters/b?i...
The whole purpose of going to the bar is to be around other people, the whole point of watching sports at a bar is to enjoy it together.
That's the difference in £200 speaker * tables vs that + poe gear, engineer and cable install that must what 10 grand? And now you can't rearrange the tables for a wedding party.
These are often transmitted over audio induction loop already.
However as an "regular person", I would like to be able to hear the audio announcements on the local train system (BART). The trains tends to be extremely loud so in-ear/ANC headphones are almost required for ear protection. ANC + Movie/Music = No idea what is going on or why.
I can imagine a scenario where I autoconnect to my public transit provider's broadcasts to hear announcements, but an unscrupulous advertiser spoofs the broadcast to spam me.
If there's no authentication or anyone can just broadcast, then I think the spam problem will make broadcast reception unusable in public spaces.
On various modes of UK public transport, I regularly have to listen to people who shouldn't ever be given access to a PA system struggling to complete their obligatory yet pointless announcements.
There was a period a couple of years back when Waterloo station was going to have work done over the summer and there were times in the winter and spring months leading up to it when they would announce this at EVERY single station stop, day in day out on the way in and the way home. LE Audio would have been heaven for a scenario like that!
Praise be to the heavens - we can finally have Bluetooth headphones that don't revert to low-bitrate mono if the microphone is active.
Edit: on second read, I'm not so sure LE Audio will address this issue.
"Multi-Stream Audio will enable the transmission of multiple, independent, synchronized audio streams between an audio source device, such as a smartphone, and one or more audio sink devices."
This sounds like it's referring to stereo or other multichannel audio, not bidirectional. Hopefully I'm wrong.
The current issue is that headsets only support a single stream and A2DP isn't bidirectional, so the connection has to revert to the low-fidelity Headset Profile. Multistream means that each stereo channel and the microphone should operate fully independently. If this doesn't fix the issue, then it'll be a spectacularly boneheaded error, even by the standards of the Bluetooth SIG.
1. https://markets.businessinsider.com/news/stocks/synopsys-rel...
Also why do Bluetooth create a latency, this is pure nonsense. YouTube has cached the video so instead of sending in real time audio to my headphone, why can't the YouTube app send cached audio too in order to have zero latency?
If it could recover fast enough to play the right audio in time, then it would seem that bluetooth is already low latency enough to play in real time anyway? Or am I missing something.
I can't quite tell from the website, but I'm assuming we will need new BT antennas BLE Audio support before we can use it, which sadly means yet another generation of computers & smartphones have to come out before this can become ubiquitous.
LC3 at 32 kbps (LC3 32) provides significantly better audio quality than Opus-CELT at 32 kbps and complexity level 0 (OPUS_v114_c0 and COPUS_v114_c0).
https://www.etsi.org/deliver/etsi_tr/103500_103599/103590/01...
Getting down to 700 and even 450 b/s is neat and all, but there seems (to me) to be a gap between 4000 and 10000 b/s in the patent-free space.
It doesn't seem to be a particularly lightweight codec compared to Opus, or particularly performant.
The path is almost always: input audio stream -> decode into raw PCM/PDM/TDM/whatever -> convert to whatever sample rate you're using internally -> move it to your output via some sort of audio bus -> output converts to whatever format IT needs (for bluetooth, this would be into packets to send over bluetooth... for a speaker driver, this would be into signals that drive an actual speaker)
Even if you could send Opus directly, I guarantee there's a reason that they went through the effort of developing an entirely new codec. If Opus met all their needs right off the shelf, then you bet they would spend the effort to use what already exists.
There probably is some sort of latency compensation that you could perform to alleviate this for video content (e.g., most receivers have a delay option to compensate for TV latency), but this falls apart for any instantaneous audio (e.g. button presses, video games, or other dynamic content). You want everything to run as quickly as possible.
The most obvious choice here was to allow MP3 as a codec choice, but the patents are all expired on MP3 so that's not a revenue source. Doing that would have avoided recoding for most music.
Every Bluetooth chip I've seen has enough CPU to decode any of these codecs. The only question would be power consumption during decoding.
I have a distinct suspicion that in reality the only relevant feature LC3 has which Opus lacks is that it ensures a nice ongoing stream of licensing money for the Fraunhofer Institute and Ericsson, who designed it and worked to get it into the standard.
Will this seemingly simple scenario be handled by Bluetooth LE Audio? I'm reading about its one-source:multi-sink capability with some hope.
Latency needs to be on the order of single-digit milliseconds. LC3 can achieve around 20. One order of magnitude too high.
Audio needs to not sound like it's being played underwater.
And give me 100 feet of range.
The whole point of codecs is to use less of the incredibly congested 2.4G band and deliver similar performance. There are trade-offs, such as latency, in this case.
Also, range is a component of antenna and power usage, both of which could be tailored to reach 100ft. Problem is, people would prefer smaller antennas and lower power, since 100ft of range is useless to most. There's nothing stopping Bluetooth from doing that though; it's just a matter of the devices that exist today.
Not sure I can help you on the sound quality though. That sounds like a problem with the devices you've been using. AAC or LDAC both sound fine to me... and are available on pretty much any device.
All of these could be implemented with the old Bluetooth standards but for various reasons, people haven't done it.
I think with BTLE it will be easier for systems like that to operate in an infrastructure mode. That is, really my laptop should stream audio over WiFi, then it goes over Ethernet to one or more hubs near me. That's the way you get to perceived 100% reliability.
What kind of bluetooth have you been using? Modern codecs sound perfectly fine.
The only reason you need something that supports more than SBC and AAC is because of poor AAC implementations for most Android devices. AAC is very well understood, performs well, has very inexpensive FRAND licensing, and works well for every non-Android platform.
And, as aptX has become incredibly common for Android, practically speaking audio sinks should only have to support AAC or aptX really. AAC for iOS/Windows/Mac/Linux and aptX for Android.
Check A2DP section at https://www.bluetooth.com/specifications/assigned-numbers/Au...
(Hint: If you're standing on the opposite side of the room from a TV, you're already at about 15ms of latency...sound moves at approx. 1ft per ms)
Many TVs are already delaying the audio by a frame or two anyway due to all the processing they do.
It's a very very different set of requirements than real time recording/instrument playback.
According to this chart[0], I would say worst case scenario people are sitting 10 feet away from their television. Not to mention 15ms would imply you're 15 feet away, which I don't think is the average room size for most people.
I would average worst case scenario would be 10 feet, so 10ms, and average best case would be 3 ms if you're sitting in front of your computer with speakers.
[0] https://www.crutchfield.com/S-DxEcQ1ASZo9/learn/learningcent...
Not when you're wearing headphones and playing along with the music with your guitar. 20ms is more than enough to throw off even the most professional musician's timing. It's enough to throw off opera orchestral performance (and I've had it happen performing at Forrest Lawn Glen Avon near Walt Disney's tomb.)
This is why I'm still using wired headphones. Latency is unacceptable in my hobbies.
WHEN YOU ARE PLAYING ALONG you need to have the timing right. That means if I set the orchestra off, hit play on my metronome, and my beat is half a measure off, we just screwed up, especially when we're doing things like musically-timed parts of the on-stage performance. Or when I hit play on our Silent Movie with original orchestral score made by local musicians nights. Timing goes off, everything feels wrong.
You'd need to be an actual performer to understand this, I suspect.
In my actual use case, IT IS NOT. I'm playing ALONG with that music. And that music is piped into the SAME SET OF HEADPHONES as my guitar is also run into the computer. The latency of what I will hear music-wise, try to time along to, play, and then hear my guitar played back to me, would be roughly 40 or 50ms because of the additional input lags. Absolutely unacceptable to any serious musician. Add another 150ms or so if you're trying to hear your guitar by simply selecting the garbage "Listen to this device" option in the Windows Sound Mixer of any vintage after XP, as opposed to trying to listen to your guitar and time it with everything by unmuting in your sound card drivers for practically zero latency (if they even offer that option. It seems to be getting rarer and this was bog-standard on regular onboard audio back in the day.)
I've already tried this with Bluetooth before. This is why I already know about this in such depth, and have a mixer board hooked up to my computer, where everything is hard-wired and pretty much latency-free. Bluetooth simply isn't there, and likely will not be any time soon.
Also what about AptX LL? Or LLAC?
The timing accuracy for professional musicians can approach 1ms under controlled tests. The human auditory system is extremely sensitive to timing differences, among other reasons, because we use these timing differences to localize sound. 10ms is about equivalent to a 3m distance in space. So if you have a 10ms delay on your guitar, it sounds like you are playing a guitar that is 10 feet away from you.
One of the tradeoffs in latency for fidelity is that the two major components of lossy codecs (the filterbank and DCT) have an inverse relationship between quality of encoding and fundamental latency built into the algorithms.
The solution to your needs is a pro audio product developed by Shure or Sennheiser, not consumer electronics like bluetooth.
https://assets.sennheiser.com/global-downloads/file/12186/SK... - 3ms
https://www.shure.eu/productdocumentsfiles/default/products/... - 4ms
Opus can achieve reasonable lossy compression ratios with 2.5ms packet sizes using its CELT half, which uses MDCT, so it’s definitely possible to achieve high quality under these constraints. I doubt it would make sense with Bluetooth LE because of the complexity of the codec.
I have a Shure wireless guitar/microphone transmitter - latency purely determined by device distance as it's totally analog and doesn't need/use a codec. That's pro-level audio equipment from the early 90s ($250 back then.) Literal atmosphere-limited light speed.
Today's stuff is literal garbage. Even the latest Shure wireless stuff can't keep up with the higher frequencies on my guitar and attenuates/dampens them.
At that latency I can see lips move before I hear audio. Very disconcerting.
Either that or the whole ordeal will be hilarious to watch.
BT5 does make things better if for no other reason than less re-transmits vs 4 in the same conditions.
I wonder how much the real-world latency is. If the codec itself is only adding 20ms, what about the rest of the system?
I would not believe the 20ms number without real world performance benchmarks tested in operational conditions for my specific product but if that is what is actually happening, I suspect something with the implementation on the specific platform is to blame - again, the standard is ridiculously complex and hard to implement. It's notoriously bad on android (by bad I mean a dumpster fire) and while windows is actually been making progress, depending on the SoC of the physical adapter your experience can range from great to near android level dumpster fire.