Yesterday the Bluetooth SIG has announced and released the newest Bluetooth standard for audio playback: LE Audio. The new standard is a complete new redesign of the audio stack, building upon the years of learnings that we’ve seen with Bluetooth audio in the past. The new LE Audio standard expends the flexibility and functionality of audio playback over Bluetooth, and is said to represent the new baseline for future developments over the next decade.

Traditional audio playback should be a familiar matter with everybody in the industry as well as consumers. The existing audio stack has now been renamed to “Classic Audio”, and will continue to coexist alongside the new LE Audio standard.

So what does LE Audio bring? The most important aspect of the new standard is self-explanatory and divulged in its very name; it’s based on the new Bluetooth Low Energy radio as opposed to the Bluetooth Classic radio. As a reminder, LE radio is fundamentally different to the classic radio standard and significantly improves upon the power efficiency of transmissions.

LE Audio also brings a lot of new features and helps today’s TWS (True Wireless Stereo) use-cases that we’ve seen over the last few years. TWS audio products nowdays mostly rely on one earpiece receiving the data signal from the transmitter device, and then re-transmits this to its other channel sibling. This is quite inefficient as you might imagine, as you have to transmit from what is usually a very battery limited device. LE Audio now standardises multi-stream transmissions – the source device is the one who handles transmissions of multiple synchronized streams, so for example a smartphone will be able to transmit to both left and right earpieces in TWS products. It is said that the synchronisation here is in the tens of microseconds, allowing for seamless and transparent playback.

There were multiple companies at the launch event showcasing this capability:

Goodix showcased a production ready development platform with their chipsets, with two of them powering a pair of headphones with flawless synchronisation. Goodix’s demo is Bluetooth 5.1 compliant and supports LE ISOC (isochronous) architecture, which is the official name for this part of the LE Audio standard.

Qualcomm also had a development board showcasing the same feature. Other companies launching LE Audio ISOC solutions were CEVA, Nordic, Dialog and various other vendors.

LE Multi-Stream is envisioned to be able to able to support an unlimited amount of devices when in broadcast mode. Use-cases for this are envisioned to be events and location based broadcasts such as museums or other gatherings, where one would be able to tune into the audio broadcast. It’s to be noted that streams can also be protected as well as public.

Broadcasting also serves as the basis for Audio Sharing, where one can share playback with multiple devices in your immediate surrounding.

The most important aspect of LE Audio is that it brings with it a brand new base audio codec which massively improves upon the aging and lacklustre SBC standard. LE3 (Low complexity communications codec), is actually a quite complex new codec that promises major upgrades in transmission efficiency as well as audio quality.

The most interesting demonstration at the launch event was that of Tim Reilly of T2 Labs. The showcase here was a software demonstration with the ability to seamlessly switch between codecs during audio playback. Tim demonstrated SBC vs LC3 vs no compression, with users being able to hear the difference with the demo headphones.

There were several comparisons to be made. In an equal bitrate scenario at lower absolute bitrates, LC3 was able to blow SBC out of the water in terms of quality. In general, audio quality would only equal out between the two codecs only when SBC had 3x higher bitrate. In essence, LC3 either allows for three times better quality, or three times less energy used when transmitting audio.

The comparison between LC3 and no compression was also very interesting. Although it was quite a noisy environment, I was unable to discern differences in audio playback quality once the LC3 bitrate reached 192kbps. Let’s say that 256kbps would be damn near transparent in terms of quality. 128kbps the differences started to be audible, but still incomparable to how bad SBC sounds at this bitrate.

The LE Audio standard will be released as several standalone specifications for each feature over the course of 2020. What all the features have in common though is that they rely on a new Bluetooth 5.2 core specification, which was publicly released yesterday.

The Bluetooth SIG expects chip manufacturers to be able to release new designs supporting LE Audio over the course of the next year to 18 months, with consumer products (sources and sinks) to closely follow that timeline, with an expected timeline of 18-24 months.

Overall, LE Audio seems to be addressing some of today’s major shortcomings with Bluetooth audio, and most importantly it standardises a new much more capable codec that will hopefully bring some unison to today’s fragmented BT codec landscape. We’re looking forward to the first devices supporting LE Audio and LC3.

Comments Locked


View All Comments

  • 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

  • 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 $$$$$.
  • 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).

Log in

Don't have an account? Sign up now