Announcing Bluetooth LE Audio(bluetooth.com)
bluetooth.com
Announcing Bluetooth LE Audio
https://www.bluetooth.com/learn-about-bluetooth/bluetooth-technology/le-audio/
107 comments
The killer application for this technology is a bicycle bell you can use to break the trance of phone-staring pedestrians who are randomly staggering down the pavement.
Once you can do that the killer app will be intrusive ads.
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).
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).
In Borderlands: The Pre-Sequel/Claptastic Voyage there's an enemy called an Adbug.
"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.
"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.
I don't think this is how it will work. Broadcasting won't immediately interrupt others' connections.
Its bluetooth, there will be bugs and crappy implementations. https://en.wikipedia.org/wiki/Bluesnarfing https://en.wikipedia.org/wiki/Bluejacking
A bicycle is a road vehicle. You shouldn’t be riding on the sidewalk.
Thank you for sharing the customs of your people and/or jurisdiction.
There are valid shared bike/pedestrian spaces, like bike trails. Zoned out pedestrians on phones/headphones are extremely common there.
Yes, they can be extra dangerous if they have, say, a curious dog on a long leash on the other side of said trail while they’re busy counting Facebook likes
Ah, you must be related to the person from the other day who told my TEN-YEAR OLD to get off the sidewalk because it's illegal.
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).
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).
I’m sorry you were held down and forced to scream at someone two blocks away in public. Hopefully somebody some day will invent a kind of faster-than-foot travel you could use to catch up to someone instead.
I know, right? I'm sure the inventor of such a device could make a lot of money.
Is this a language problem? Apparently [0] in BE it means sidewalk, but not in AE.
[0]: https://www.merriam-webster.com/dictionary/pavement
[0]: https://www.merriam-webster.com/dictionary/pavement
What's with the downvoting?
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
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
Riding on the road is even more dangerous in some areas, though.
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.
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.
That kind of reasoning wouldn’t make me feel better if I were the pedestrian who had to go to the hospital. You make it sound like bicycles are just an inherently bad thing to have around :)
If we're fantasizing about eliminating some mode of transport, my vote is for cars. Most of my initial parent comment's concerns would go away if there weren't any cars, and pedestrians would be safer on crosswalks too.
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.
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.
It's worse now that Lime and other bicycle rental startups have littered the sidewalks with bicycles. When I'm not running around a bike left on the sidewalk, I'm getting run over by somebody riding one on the sidewalk.
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.
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.
I imagine the downvoting is due to your erroneous projection of the customs of your locale to the entire larger world. Even narrowly considered, your links don’t really support your point of view (eg there are numerous shared pedestrian/bicycle paths in California, children are allowed to cycle on sidewalks in California, etc).
It would be great for the array of TV's at the gym. Mine currently has a headphone jack on each treadmill with a keypad that you can tune into your preferred channel. I've taken to watching Netflix with Bluetooth head phones vs trying to use a wired pair while I run.
3.5mm Bluetooth Transmitter
https://www.amazon.com/MP3-Player-Bluetooth-Transmitters/b?i...
https://www.amazon.com/MP3-Player-Bluetooth-Transmitters/b?i...
Agreed, plus everyone at the bar can listen to whichever game they want without annoying everyone else. That is killer.
So you go to a bar, don't talk to people, and listen to a specific game solo. Why not just stay at home? The other examples named above make sense, this one seems like a stretch.
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.
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 works fine when there is only one game one. How does a bar full of people listen to three separate college football games going on at the same time? Also, a lot of people are introverts and like to be around other people without being forced to contribute to conversation. You can feel part of the crowd with being in it.
You could have a speaker on every table without wiring the place all day.
I suppose, but they'd still need electricity so running PoE is no harder and then you aren't worrying about things like interference.
Yeh, that's the logic I apply to CCTV installs. But a restaurant could easily swap drill batteries out of table speakers at cleanup every night.
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.
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.
> 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.
These are often transmitted over audio induction loop already.
These are often transmitted over audio induction loop already.
Ah, fair point. As I'm not hard of hearing I don't think about those technologies much.
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.
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.
Maybe it would be possible to receive inductive loop on your headphones.
I wonder how this will fare with spam. If I'm to have autoconnection, for example, then the broadcaster will need to be authenticated.
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.
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.
The mass transit point would get my vote, specifically so you can ignore them more effectively than is currently possible (even with noise cancelling headphones).
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!
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!
Tune into the arcade game or pinball machine you're playing.
>LE Audio is Multi-Stream
Praise be to the heavens - we can finally have Bluetooth headphones that don't revert to low-bitrate mono if the microphone is active.
Praise be to the heavens - we can finally have Bluetooth headphones that don't revert to low-bitrate mono if the microphone is active.
YES! This has been bothering me for so long. I'm shocked it's taken them this long to iron it out. I hope the device manufacturers implement it soon.
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.
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.
>on second read, I'm not so sure LE Audio will address this issue.
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.
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.
[deleted]
I’m really looking forward to a new range of incompatibilities between Bluetooth audio devices, as well as the new complications this introduces into the Bluetooth software stack.
Will phones/computers that have bluetooth 4 or 5 be able to transmit bluetooth LE audio? Is it just a BLE feature that can be added in software, or is it a completely new standard?
Most likely no. LE Audio requires controller support for Isochronous channels which is major part of Bluetooth 5.2. Usually firmware updates for bt chipsets are more like bug fixes than new features.
Not to mention majority of devices on the market already ship from the factory with depleted firmware update slots. https://www.youtube.com/watch?v=4_nI9ok7iQg
Where can I find more about LC3 codec? What about LE audio specs? Is this open source or do they sell licenses for this?
I too am interested in this. The only thing I've been able to dig up so far is that it's a new codec, built for BT LE Audio, that seems to have been designed by Synopsys[1]
1. https://markets.businessinsider.com/news/stocks/synopsys-rel...
1. https://markets.businessinsider.com/news/stocks/synopsys-rel...
[deleted]
Why do we need another codec than opus? Is it complementary?
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?
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?
Interesting idea! This introduces the same problems that an online game suffers though. 90% of the time you can predict successfully what is playing, but as soon as one scrubs, or pauses the video, the signal already sent to the headphones would be out of sync. Not sure how that is fixed without delaying the video also.
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.
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.
Specifications will be published during the first half of 2020. Afaik specs will be public but some kind of qualification may be required.
I personally would not have predicted something like this was needed. How long has this been in the works? Now that I can see how useful this is, I'm amazed this didn't happen much sooner. Is this one case where "we" knew we needed it, but the tech just wasn't available?
Bluetooth LE uses substantially less battery than older Bluetooth devices do. It makes a big difference for anything that's battery powered. I was really bummed when I found out BLE didn't support audio at all.
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.
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.
I love the use case of being able to sync with local audio sources, whether in the gym, the airport, a cafe, or a retail store. I wonder if an "audio sink" can then turnaround and rebroadcast the input to a different sink, creating a sort of chain of local communication?
Is LC3 superior to existing codecs like Opus?
Opus is not low complexity
Found this:
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...
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...
I'm of the opinion that Codec 2 [0][1] should pause on trying to perform better at lower and lower bit rates, and put some work into higher ones.
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.
* [0] http://www.rowetel.com/?page_id=452
* [1] https://en.wikipedia.org/wiki/Codec_2
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.
* [0] http://www.rowetel.com/?page_id=452
* [1] https://en.wikipedia.org/wiki/Codec_2
opus_256k can decode in real time on ~40MHz arm9 from 1999, or 16MHz DSP core https://www.synopsys.com/dw/ipdir.php?ds=arc_audio_opus_code...
For comparison, Synopsys' LC3 codec implementation: https://www.synopsys.com/dw/ipdir.php?ds=arc_lc3_codec
It doesn't seem to be a particularly lightweight codec compared to Opus, or particularly performant.
It doesn't seem to be a particularly lightweight codec compared to Opus, or particularly performant.
I don't get it, if I watch an opus music on YouTube, will my headphone transmute opus into LC3? Why this indirection and overcompression?
Latency shouldn't exist at all with opus anyway, YouTube just has to send cached audio to the headphone.
Because that requires a Bluetooth processor that can decode Opus. Also, it's a lot less simple than that. You aren't sending the raw audio file to the Bluetooth chip, you're sending an internal audio stream which is already getting converted anyways.
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 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.
I suspect the main reason they created a new codec is to collect a few billion in royalties.
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.
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.
You arent wrong. Look at Dolby and their clever injections into every new standard despite both HDMI and Bluray already provisioning uncompressed LPCM 7.1 channel audio.
Sure, most Bluetooth chips CAN decode most codecs... but it's a matter of power efficiency. If you're trying to make things as efficient as possible, you don't want something that can decode a bunch of different codecs. More specialized means it should be more efficient.
In practice, these codecs are all going to be decoded in firmware on a DSP anyway - while the hardware is optimized for efficient implementation of algorithms like this, which one doesn't matter so much. Also, LC3 seems to have roughly the same computational complexity on one as Opus based on the figures I've seen, and about the same quality too.
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.
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.
Scenario: Two people, quiet room, watching TV, each wearing their own Bluetooth headphones to listen together. As I understand Bluetooth audio standards, until now, this is impossible without additional hardware to split the source and allow multiple 1:1 pairings. Ugh.
Will this seemingly simple scenario be handled by Bluetooth LE Audio? I'm reading about its one-source:multi-sink capability with some hope.
Will this seemingly simple scenario be handled by Bluetooth LE Audio? I'm reading about its one-source:multi-sink capability with some hope.
In slightly related news, does anyone know where in the Bluetooth spec soft power buttons are required? (press for three seconds to turn on, oh wait it was already on, not it's off, press for three more seconds...) My biggest complaints with Bluetooth are exacerbated by the fact that it's not possible to flick a power button off and back on again.
Just yesterday I was discussing how one might do live translation for someone speaking to a multi-lingual group, for example a tour guide at a museum. The broadcast features mentioned here would make things way easier, and people could use their own headphones to boo.
This literally addresses none of my complaints regarding Bluetooth Audio.
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.
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.
You're asking for a lot of pretty specialized things that don't really address the broader market. If you truly need single-digit ms latency, wired solutions or proprietary wireless is going to be better.
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.
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.
For the 100 feet you need more power, better antennas, and diversity reception at the headphone end.
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.
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.
"Audio needs to not sound like it's being played underwater."
What kind of bluetooth have you been using? Modern codecs sound perfectly fine.
What kind of bluetooth have you been using? Modern codecs sound perfectly fine.
My fancy Sony headphones sound great until I need to make a call whereupon they revert to HSP which sounds awful...
[deleted]
Modern codecs are non standard vendor extensions.
What do you consider a 'modern' codec? SBC is the only codec that basically can't sound good. AAC, MP3, and even ATRAC can all easily deliver 'CD Quality' sound over bluetooth, and they are all officially part of the A2DP spec. Not required codecs, but part of the spec and far from a 'non-standard vendor extension'.
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...
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...
20ms for playback of media is totally fine.
(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.
(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.
That seems like too much.
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...
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...
Imagine being at the bar or gym, which is the sort of use case being thrown out in this thread. 15ft is low, if anything.
"20ms for playback of media is totally fine."
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.
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.
Again, performing is not playback.
You're making assumptions without all of the information.
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.
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.
I'm not making any assumptions. You're the one who keeps bringing "playing along" and "timing" into it. That's not what this is about...at all.
You said 20ms of latency is fine for media playback.
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.
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.
What is your use case for low latency? I understand that some want it for bluetooth headsets for videogames, where milliseconds mater - but beyond that?
Also what about AptX LL? Or LLAC?
Also what about AptX LL? Or LLAC?
I play guitar. Timing is absolutely necessary. Anything past 15ms I can perceive and it is highly distracting and off-putting to my internal metronome.
Sure. Playing music makes sense. I was just curious why people cared about 10-20ms of latency on what I see as "movie on iPad on Plane". Clearly there are many other use cases.
"I was just curious why people cared about 10-20ms of latency on what I see as "movie on iPad on Plane""
At that latency I can see lips move before I hear audio. Very disconcerting.
At that latency I can see lips move before I hear audio. Very disconcerting.
If you are a musician, try introducing a 10ms or 20ms delay and then play something on piano or guitar. Whether you notice it depends on a ton of factors which I’m not going to get into, but in general, at 10ms the music will feel sluggish and you will have difficulty playing on the beat. This can be verified with ABX tests if you like.
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.
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.
Be happy you are not an organist :-). My sister is and turns out large pipe organs have like 250ms or more of latency. It becomes incredibly demanding to stay in time during a performance.
You're not wrong, but I suggest you go out and measure the latency of pro audio wireless systems that have proprietary and specialized low-latency audio codecs. They push 10-15ms, depending on the source content. Often they trade fidelity for latency. They're also rather pricey, because it's a specialized use case.
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.
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.
The wireless systems I am thinking have published latency specs of something like 3ms, for example. It’s not worth the cost for my uses so I just stick with wires. I’m not sure which systems you are referring to that have 10ms latency, but I haven’t worked with many wireless systems so it could just be a lack of experience on my part.
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.
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.
"You're not wrong, but I suggest you go out and measure the latency of pro audio wireless systems that have proprietary and specialized low-latency audio codecs."
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.
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.
Sounds like you want a magic solution. At least if you don’t want to compromise on anything else such as distortion due to packet loss and power consumption. Bluetooth Audio is not designed for your use case. You’ll just have to deal with that.
really interested in latency here
It's not mentioned, seeing as this was a press release if it was better than the current standard then one would assume they would have mentioned it. Assuming this is the case, 200-500ms in real world conditions. With super duper non-standard proprietary tech on both ends from vendors like Qualcomm it can be in theory be as as low as 32ms, but in practice I don't see those numbers. New airpods with apple's proprietary tech get mid 100s ms of latency and that is considered pretty good for BT headphones in the real world.
BT5 does make things better if for no other reason than less re-transmits vs 4 in the same conditions.
BT5 does make things better if for no other reason than less re-transmits vs 4 in the same conditions.
Yeah, according to some news articles, I see Airpods Pro have a latency of ~144ms end-to-end. I haven't noticed that latency when I watch videos on my phone... On the other hand, I definitely noticed the latency with a much cheaper pair of true wireless earbuds. They probably had the ~500ms latency you mention.
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 wonder how much the real-world latency is. If the codec itself is only adding 20ms, what about the rest of the system?
Definitely not an expert in BT but I've worked with it on the edges. Bluetooth is the biggest standard I've ever worked with by far in just terms of sheer page count, to say nothing of its complexity. That's just the core spec, not any of the other pieces you need too to make it do useful work.
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.
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.
I don’t know about the specific latency, but I know it’s significantly improved over classic Bluetooth.
do i have to invent the system for ~1 ms latency? serious question. needed for music. anyone trying to solve this yet?
Odd that they don't include power consumption specs.
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.