Hahaha, thanks, glad to know I'm not the only person who read this and wondered WTF SIG members. It's prolly full of old dudes that don't game or youtube :-(
That's just plain demeaning to old people: if you used Google instead of "gaming or youtube", you'd realize that LE Audio is designed for use in a far more important low-latency environment: hearing aids. All signs point to a lower latency in the protocol.
Needless to say, I'm sure you'll enjoy that benefit, too, to "game and YouTube".
If you keep Google'ing, instead of the "games and youtube", you'll see that LC3Plus (a superset of LC3) has a mode for ultra-low latency: 5ms packet size, far better than AptX-LL (if we're comparing apples to apples).
And your "further reading" confirmed your nonsense. Under LC3 it's stated LC3 will be part of BT LE as mandatory codec. LC3plus while being listed as standardized, is NOT being considered to be incorporated into BT LE at all.
I think latency will be majorly improved: Bluetooth SIG specifically mention Bluetooth LE Audio being used for hearing aids, which require very low latency:
"LE Audio will enable the development of Bluetooth hearing aids that bring all the benefits of Bluetooth audio to the growing number of people with hearing loss.
...
LE Audio will be one of the most significant advances for users of hearing aids and hearing implants. EHIMA engineers have contributed their specialist knowledge to improve the audio experience especially for hard of hearing people. As a result, within a few years most new phones and TVs will be equally accessible to users with hearing loss."
That's the problem, it has to support it in addition to BT standard, while ANY BT 5.2 must support LC3. We can even expect BT 5.1 compliant devices to emerge by the end of the year that supports LC3, and the benefit of those devices is it's future-proof, meaning it can connect to ANY future BT 5.2 devices with LC3. While if you bought into AAC or apt-X ecosystems, there's no such garantee, you still must look for those additional codec.
As far as I can tell, LC3 has an algorithmic delay of 12.5ms, much less than AAC LD's 20-30ms. So the total hardware delay should be around 25-40ms. So under 30ms should be realistic. For comparison, AAC LD can achieve 35-45ms realistically. This should be good enough for any consumer applications.
The largest driving factor causing latency in Bluetooth headphones is the buffer that is used to store 200-300ms of audio in case of intermittent radio interference. The new codec will allow for similar quality audio at a much lower bit rate. A lower bit rate allows for less airtime which means there is less chance for the radio to have interference and more opportunities to recover from dropped audio packets. This will allow for lower latency use cases.
I don't think it works that way, for example h265 is better than h264, but only at lower bitrates, if we get to the point that film grain is preserved (like proper bluray) h265 has no advantage over h264, so the majority of current bdrips (not the overcompressed stuff that's hardly better than hdtvrip) are still h264.
The "listening test" is indeed the most important empirical tool for evaluating if audio is good enough. However, they don't mention what kind of audio was played back. You can make a sine wave sound good but I don't want to spend money on a wire replacement that makes cymbals, pianos, and snares sound like crap.
Nail on the head. 802.11 vs 802.3: it's a different ballgame with wireless (plus balancing power consumption vs quality vs latency, compromises storage codecs rarely concern themselves with & thus leave a *lot* of end-user performance on the table).
I get the theoretical concern. But are there real world indications that this matters? I cannot think of a single instance where I noticed a glitch in my AirPods audio (ie AAC) from a lost packet. Is this packet lost known to be a problem in some environments (maybe a subway car with 50 BT users?)
Hopefully, they at least start including the OPTIONAL Bluetooth 5 long range mode in more wireless headphones, since 125 kbps can transmit decent audio... particularly Opus audio.
I do wish it'd been Opus, or at least an Opus superset. But, I will say one serious benefit may be that LC3 was designed specifically for wireless transmission. From the authors,
"To improve robustness, LC3plus contains a very high-performance packet loss concealment algorithm as well as forward error correction schemes such as channel coding or redundancy frame modes."
"In terms of robustness, LC3plus’s channel coding, which was specifically designed for DECT channel characteristics, permits the transmission of LC3plus payloads over heavily distorted DECT channels – enabling phone calls without interruption, even if the handset is far away from the base station."
An analogy: 802.11 (wireless Wi-Fi) is a very different specification than 802.3 (wired Ethernet), even though they carry the same underling data. Now, could Opus have been updated/tweaked for a specific wireless mode? Probably and it was probably because of $$$$$.
Matroska sucks. It seems like a good idea, until you actually go to write some code or dig into the details of the format. Turns out, it's just garbage. But it's free garbage, so people like it.
That's compared to most containers which are... unambitious at best. Things like Ordered Chapters (splitting a single playback into multiple deduplicated chunks that may be shared between files, e.g. a TV series that encodes and stores the opening sequence once rather than per-episode) is not available elsewhere and ends up being implemented via dodgy hacks (e.g. BD's transport stream switching).
Bluetooth has 3 problems. Sound quality (sure it is good enough so move on), then latency (devices not syncing correctly video and audio for example) and for me, the killer is 2 channels.
We need good 3 channel support for stereo sound and microphone at the same time... until that time, I won't use it. Maybe they'll get it right in 2030? Because everything bluetooth has been garbage imo for almost 20 years now... I won't wait any longer.
maybe i don't understand, but will the next standard allow 3 streams, one to each ear (as this suggests) and then to a microphone part of a headset also?
The average consumer should be familiar with the classic audio stack? I know a lot of users (at my office, as an example) who have accomplished something if they've turned on their computers and logged in without asking for help.
I’d ask this from a different angle: what does LC3 do better than AAC and HE-AAC?
I’m prepared to accept that codecs evolve, and AAC will not be optimal forever. (cf MPEG1/2 -> 264 -> 265.) But right now this looks a whole lot like nothing more than NIH...
So LC3 gives 5, 7.5 or 15ms. AAC ULD gives maybe 15ms. That reduction is clearly nice. Let’s see, when implementations come out, how well it works in practice compared to AAC.(Apple uses AAC-LD [~25ms] for FaceTime. I don’t know if they use AAC-ULD anywhere.)
You appeared to be separating the various flavors under the aac name, so it wasn't clear that you meant uld. If you want to use an existing code opus is better. Latency down to 5ms, degrades gracefully from packet loss, and becomes aurally transparent pretty much as early as anything out there.
I don't think the article mentioned it, but PLEASE let this have microphone support. I'm sick of bluetooth devices switching to the headset profile with garbage mono sound to be able to use the mic!
The way the headphone is connected to the prototype seems kind of stupid. IF you have to solder it on, just solder on something that terminates at a female 3.5mm connector and plug the headphone into that instead. But that may just be me.
I think the biggest benefit of this over aptx and the likes is that its a standard used over all bluetooth devices. Where a lot of headphones still fell back to sbc because they had to deal with qualcom this should be a lot better license wise.
We’ve updated our terms. By continuing to use the site and/or by logging into your account, you agree to the Site’s updated Terms of Use and Privacy Policy.
Facebook
Twitter
RSS
48 Comments
Back to Article
hubick - Tuesday, January 7, 2020 - link
This doesn't mention what is really the most important thing: Latency!Most current Bluetooth headsets have 200-300ms latency, which makes watching video suck (poor lip sync) and playing video games just about useless.
There are low latency (50-75ms) codecs like Qualcomm's AptX-LL, but those aren't widely supported and you can't even use them with a PC.
So, yeah, if we're going to live in a wireless audio world, that really kinda needs to be worked on, and I'm not hearing a peep here?
mukiex - Tuesday, January 7, 2020 - link
This this this this this. ^^^^I've got literally nothing to bring to this conversation except to say that hubick is all kinds of correct.
hubick - Tuesday, January 7, 2020 - link
Hahaha, thanks, glad to know I'm not the only person who read this and wondered WTF SIG members. It's prolly full of old dudes that don't game or youtube :-(ikjadoon - Tuesday, January 7, 2020 - link
That's just plain demeaning to old people: if you used Google instead of "gaming or youtube", you'd realize that LE Audio is designed for use in a far more important low-latency environment: hearing aids. All signs point to a lower latency in the protocol.Needless to say, I'm sure you'll enjoy that benefit, too, to "game and YouTube".
For everyone else: https://www.bluetooth.com/learn-about-bluetooth/bl...
ikjadoon - Tuesday, January 7, 2020 - link
If you keep Google'ing, instead of the "games and youtube", you'll see that LC3Plus (a superset of LC3) has a mode for ultra-low latency: 5ms packet size, far better than AptX-LL (if we're comparing apples to apples).ikjadoon - Tuesday, January 7, 2020 - link
For further reading: https://www.iis.fraunhofer.de/en/ff/amm/communicat...levizx - Wednesday, January 8, 2020 - link
And your "further reading" confirmed your nonsense. Under LC3 it's stated LC3 will be part of BT LE as mandatory codec. LC3plus while being listed as standardized, is NOT being considered to be incorporated into BT LE at all.levizx - Wednesday, January 8, 2020 - link
Exactly, it's a SUPERSET, and LE Audio only mentioned LC3 being supported, you CANNOT assume LE audio support it. In factsorten - Tuesday, January 7, 2020 - link
LOL @ old dudes, considering the first image in this article.ikjadoon - Tuesday, January 7, 2020 - link
I think latency will be majorly improved: Bluetooth SIG specifically mention Bluetooth LE Audio being used for hearing aids, which require very low latency:"LE Audio will enable the development of Bluetooth hearing aids that bring all the benefits of Bluetooth audio to the growing number of people with hearing loss.
...
LE Audio will be one of the most significant advances for users of hearing aids and hearing implants. EHIMA engineers have contributed their specialist knowledge to improve the audio experience especially for hard of hearing people. As a result, within a few years most new phones and TVs will be equally accessible to users with hearing loss."
https://www.bluetooth.com/learn-about-bluetooth/bl...
subtec - Tuesday, January 7, 2020 - link
You can use AptX-LL with a PC with a Bluetooth transmitter that supports it.levizx - Wednesday, January 8, 2020 - link
That's the problem, it has to support it in addition to BT standard, while ANY BT 5.2 must support LC3.We can even expect BT 5.1 compliant devices to emerge by the end of the year that supports LC3, and the benefit of those devices is it's future-proof, meaning it can connect to ANY future BT 5.2 devices with LC3. While if you bought into AAC or apt-X ecosystems, there's no such garantee, you still must look for those additional codec.
levizx - Wednesday, January 8, 2020 - link
As far as I can tell, LC3 has an algorithmic delay of 12.5ms, much less than AAC LD's 20-30ms. So the total hardware delay should be around 25-40ms. So under 30ms should be realistic.For comparison, AAC LD can achieve 35-45ms realistically.
This should be good enough for any consumer applications.
ezra7 - Wednesday, January 8, 2020 - link
The largest driving factor causing latency in Bluetooth headphones is the buffer that is used to store 200-300ms of audio in case of intermittent radio interference. The new codec will allow for similar quality audio at a much lower bit rate. A lower bit rate allows for less airtime which means there is less chance for the radio to have interference and more opportunities to recover from dropped audio packets. This will allow for lower latency use cases.faiakes - Tuesday, January 7, 2020 - link
How does it compare to APTX-HD or just regular Aptx?Andrei Frumusanu - Tuesday, January 7, 2020 - link
I wasn't able to compare, but it's 3x better than SBC so you can correlate from there.s.yu - Thursday, January 9, 2020 - link
I don't think it works that way, for example h265 is better than h264, but only at lower bitrates, if we get to the point that film grain is preserved (like proper bluray) h265 has no advantage over h264, so the majority of current bdrips (not the overcompressed stuff that's hardly better than hdtvrip) are still h264.willis936 - Tuesday, January 7, 2020 - link
The "listening test" is indeed the most important empirical tool for evaluating if audio is good enough. However, they don't mention what kind of audio was played back. You can make a sine wave sound good but I don't want to spend money on a wire replacement that makes cymbals, pianos, and snares sound like crap.Andrei Frumusanu - Tuesday, January 7, 2020 - link
I listened to a variety of music tracks. It sounded very good at and after 192kbps.mooninite - Tuesday, January 7, 2020 - link
Why didn't they use Opus? Oh, yeah, so they can license yet another codec. :(There's too many codecs in the world. I'm dreaming of a fantasy world where only AV1, Opus, and FLAC survive inside of Matroska containers.
Andrei Frumusanu - Tuesday, January 7, 2020 - link
Storage codecs don't have the same requirement as transmission codecs, you essentially need a codec that deals with possible data interruptions.ikjadoon - Tuesday, January 7, 2020 - link
Nail on the head. 802.11 vs 802.3: it's a different ballgame with wireless (plus balancing power consumption vs quality vs latency, compromises storage codecs rarely concern themselves with & thus leave a *lot* of end-user performance on the table).name99 - Tuesday, January 7, 2020 - link
I get the theoretical concern. But are there real world indications that this matters?I cannot think of a single instance where I noticed a glitch in my AirPods audio (ie AAC) from a lost packet.
Is this packet lost known to be a problem in some environments (maybe a subway car with 50 BT users?)
londedoganet - Wednesday, January 8, 2020 - link
Latency.olafgarten - Thursday, January 9, 2020 - link
The reason you don't notice it is because there is enough delay to resend missing packets.tuxRoller - Wednesday, January 8, 2020 - link
Opus uses a FEC, same as lc3.nandnandnand - Tuesday, January 7, 2020 - link
A million times this.Hopefully, they at least start including the OPTIONAL Bluetooth 5 long range mode in more wireless headphones, since 125 kbps can transmit decent audio... particularly Opus audio.
ikjadoon - Tuesday, January 7, 2020 - link
I do wish it'd been Opus, or at least an Opus superset. But, I will say one serious benefit may be that LC3 was designed specifically for wireless transmission. From the authors,"To improve robustness, LC3plus contains a very high-performance packet loss concealment algorithm as well as forward error correction schemes such as channel coding or redundancy frame modes."
"In terms of robustness, LC3plus’s channel coding, which was specifically designed for DECT channel characteristics, permits the transmission of LC3plus payloads over heavily distorted DECT channels – enabling phone calls without interruption, even if the handset is far away from the base station."
An analogy: 802.11 (wireless Wi-Fi) is a very different specification than 802.3 (wired Ethernet), even though they carry the same underling data. Now, could Opus have been updated/tweaked for a specific wireless mode? Probably and it was probably because of $$$$$.
https://www.iis.fraunhofer.de/en/ff/amm/communicat...
https://www.etsi.org/deliver/etsi_ts/103600_103699...
mode_13h - Tuesday, January 7, 2020 - link
Matroska sucks. It seems like a good idea, until you actually go to write some code or dig into the details of the format. Turns out, it's just garbage. But it's free garbage, so people like it.edzieba - Wednesday, January 8, 2020 - link
That's compared to most containers which are... unambitious at best. Things like Ordered Chapters (splitting a single playback into multiple deduplicated chunks that may be shared between files, e.g. a TV series that encodes and stores the opening sequence once rather than per-episode) is not available elsewhere and ends up being implemented via dodgy hacks (e.g. BD's transport stream switching).Alistair - Tuesday, January 7, 2020 - link
Bluetooth has 3 problems. Sound quality (sure it is good enough so move on), then latency (devices not syncing correctly video and audio for example) and for me, the killer is 2 channels.We need good 3 channel support for stereo sound and microphone at the same time... until that time, I won't use it. Maybe they'll get it right in 2030? Because everything bluetooth has been garbage imo for almost 20 years now... I won't wait any longer.
Alistair - Tuesday, January 7, 2020 - link
maybe i don't understand, but will the next standard allow 3 streams, one to each ear (as this suggests) and then to a microphone part of a headset also?sorten - Tuesday, January 7, 2020 - link
The average consumer should be familiar with the classic audio stack? I know a lot of users (at my office, as an example) who have accomplished something if they've turned on their computers and logged in without asking for help.s.yu - Thursday, January 9, 2020 - link
lol, sad.wr3zzz - Tuesday, January 7, 2020 - link
Is LC3 good enough to displace Aptx-HD and LDAC? Regardless this would still help PC audio since Windows only support SBC.s.yu - Thursday, January 9, 2020 - link
Which is why I've simply connected a USB extension cable with a Dragonfly at the end.name99 - Tuesday, January 7, 2020 - link
I’d ask this from a different angle: what does LC3 do better than AAC and HE-AAC?I’m prepared to accept that codecs evolve, and AAC will not be optimal forever. (cf MPEG1/2 -> 264 -> 265.) But right now this looks a whole lot like nothing more than NIH...
tuxRoller - Wednesday, January 8, 2020 - link
Lower latency.name99 - Wednesday, January 8, 2020 - link
So LC3 gives 5, 7.5 or 15ms.AAC ULD gives maybe 15ms.
That reduction is clearly nice. Let’s see, when implementations come out, how well it works in practice compared to AAC.(Apple uses AAC-LD [~25ms] for FaceTime. I don’t know if they use AAC-ULD anywhere.)
tuxRoller - Wednesday, January 8, 2020 - link
You appeared to be separating the various flavors under the aac name, so it wasn't clear that you meant uld.If you want to use an existing code opus is better. Latency down to 5ms, degrades gracefully from packet loss, and becomes aurally transparent pretty much as early as anything out there.
peterfares - Tuesday, January 7, 2020 - link
I don't think the article mentioned it, but PLEASE let this have microphone support. I'm sick of bluetooth devices switching to the headset profile with garbage mono sound to be able to use the mic!dudedud - Tuesday, January 7, 2020 - link
Is BT 5.1 or 5.2 for that matter, a "software update" like 4.1 was for 4.0?Andrei Frumusanu - Wednesday, January 8, 2020 - link
BT 5.2 is the core spec without LE Audio, I'm not immediately aware of what it contains or what changes, haven't had the time to read into that.vladx - Wednesday, January 8, 2020 - link
So BT 5.0 headphones won't be updated to support them.qlum - Wednesday, January 8, 2020 - link
The way the headphone is connected to the prototype seems kind of stupid.IF you have to solder it on, just solder on something that terminates at a female 3.5mm connector and plug the headphone into that instead. But that may just be me.
qlum - Wednesday, January 8, 2020 - link
I think the biggest benefit of this over aptx and the likes is that its a standard used over all bluetooth devices. Where a lot of headphones still fell back to sbc because they had to deal with qualcom this should be a lot better license wise.s.yu - Thursday, January 9, 2020 - link
Sony's LDAC is available on all Android but for some reason the overwhelming majority of headphones lack support.olafgarten - Thursday, January 9, 2020 - link
It doesn't help that LDAC is pretty rubbish.