Post 2: Every Bit Counts (LC3)

The previous article showed that the 2.4 GHz ISM band may seem crowded but there is a lot of empty space. Wi-Fi works in wide but intermittent bursts, and most other occupants operate in narrow slices of spectrum and emit only brief data packets. That leaves much room for signals that are also narrow and brief to slip between the traffic. LC3 is the codec designed specifically for Bluetooth® LE Audio and Auracast™ to exploit this opportunity.

Each bit transmitted costs radio airtime and therefore battery life on devices that, in the case of hearing aids, may be tiny and mission critical to the user. LC3 was developed to wring the most value from the fewest bits. LC3 is short for Low Complexity Communication Codec, and its design is the key to the efficiency and resiliency that enable Auracast’s reliability.

Purpose Built

LC3 was designed by Fraunhofer IIS and Ericsson and standardized by the Bluetooth® SIG to serve devices with tiny batteries. In order to achieve that, “low complexity” is meant literally. An in-canal hearing aid, for instance, uses a battery comparable to a grain of rice and has processor power to match. Even so, it must decode audio in real time, continuously, for hours. A complex codec drains the battery fast or surpasses the processor’s capability. LC3 was built to be light first, achieving quality comparable to Bluetooth® Classic’s SBC codec at roughly half the bitrate, with processing demands modest enough for a hearing-aid-class chip, a fraction of what AAC or Opus need.

LC3 does not try to beat all codecs on all measures; it balances good quality with low bitrate, tight latency, and especially low processing demand in the right mix to enable Auracast’s surprising performance. Low processing demand, and therefore low battery impact, is probably the most important of these. It is natural to wonder why not AAC, aptX, Opus, LDAC, or any other common audio codec. AAC and LDAC chase music fidelity over a connected, buffered link; aptX optimizes for low delay but also targets quality at a high bitrate. Opus is superb across the internet but needs considerably more processing than LC3 on a hearing-aid-class chip. These are all good formats, each optimized for different jobs, but not the exact mix Auracast™ needs.

The Shape of a Packet

The previous article mentioned a standard set of parameters that we carry through the series to demonstrate how Auracast™ works: a single channel of 24 kHz sample-rate audio encoded at 48 kbps packetized every 10 milliseconds. This is a configuration drawn from Auracast’s mandatory Standard Quality tier, which we’ll come back to. LC3 encodes each 10 ms frame of sound into one packet of data totaling about 60 bytes of audio, and the radio broadcasts one packet per matching 10 ms window, known as the isochronous interval. Broadcast at a 2 Mbps data rate, that packet only needs about a third of one millisecond, a minuscule flash, to transmit on a single, 2 MHz wide, Bluetooth® LE channel.

Such short packet airtime enables two important benefits. First, collision with other transmissions is unlikely. For a packet to be corrupted, another transmitter must be sending on the same 2 MHz slice of spectrum during the same few hundred microseconds. Since the ISM band is mostly idle in time, the odds of overlap are very low. Second, sending the packet barely fills the 10 ms interval it represents. Almost all that interval is still free, leaving plenty of time for the radio to repeat the same packet again, and again on other frequencies, and leaving room for additional Auracast™ broadcasts.

A One-Way Conversation

Because Auracast™ is a true broadcast, some packets will go unreceived. Normal Wi-Fi and Bluetooth® links, for example, are two-way conversations: the receiver acknowledges each packet it gets, and any packet that goes unacknowledged is sent again. That two-way communication is how those links avoid dropped packets; they literally resend lost data. It comes at the cost, however, of processing and transmission power, and the retransmission process introduces unpredictable arrival timing (jitter). While 1:1 Bluetooth® LE Audio links do have such a handshake, Auracast™ forgoes it, and it would be impractical to try to maintain such communication with an arbitrarily large number of receivers anyway. And since Auracast™ is real-time audio, jitter would require buffering, and therefore undesired latency, at the receiver. Instead, the transmitter sends its packets and receivers catch them if they can. When a packet is lost, and in a busy area or at the edges of range some will be, the codec needs to tolerate the gap on its own. LC3 has two attributes that enable this.

The first attribute is the design choice that every frame stands alone. There is no dependency chaining the quality of one frame to the next as in interframe video codecs like H.264/H.265 or common audio codecs including MP3, AAC, and Vorbis. A single lost packet in those codecs can corrupt sound for many tens of milliseconds beyond the packet itself. In LC3, a lost packet never degrades the audio around it. The second attribute is a packet loss concealment (PLC) algorithm that often renders dropped packets imperceptible. PLC works because of how LC3 stores audio in the first place.

Storing What You Can Hear

LC3 is a transform codec, which means sound is stored in the frequency domain, not the time domain the way we usually think of and interact with raw digital audio. The raw samples of each 10 ms frame are converted to frequency coefficients, real numbers describing the frequency content of the frame, by a Modified Discrete Cosine Transform (MDCT) function. Each frequency range is called a ‘bin,’ and each bin’s coefficient carries a positive or negative sign: the polarity of the cosine wave it becomes when reproduced. An MDCT overlaps frames slightly and results in coded audio that seamlessly transitions between them.

At 24 kHz sample rate, that 10 ms frame is 240 samples which become 240 coefficients spaced roughly 50 Hz apart up to 12 kHz. At 48 kbps, each 10 ms frame receives 480 bits to describe those coefficients and how they are shaped. If spread evenly across the frequency spectrum, that would be two bits per coefficient, not nearly enough. But as a perceptual codec, LC3 spends those bits more strategically.

The relative amount of energy at one frequency often reduces our ability to discern another; loud sounds cover up quiet ones. This effect is called masking. A real audio spectrum is a mess, a drifting noise floor under layered, shifting partials, but most of that mess is masked by louder parts of the sound and therefore safe to discard. Taking advantage of this, a few dozen bits are used to describe the general shape of the entire spectrum, inexpensively accounting for every frequency band. The rest go to precisely defining the audible, unmasked frequencies. At low bitrates, most coefficients simply round to zero, contributing no detail to the sound. Luckily, LC3’s final lossless compression step (arithmetic entropy coding) requires few of our precious bits to encode even long runs of zeros. At the decoder those zeroed regions are filled with low-level synthesized noise matched to the stored spectral shape, maintaining texture and realism. Stated differently, LC3 does not store the signal; it stores what a listener can hear of it, saving significant data.

That budgeting hides the error in frequency, but it can leak in time. Every coefficient describes a cosine wave that lasts the whole 10 ms frame, so when each coefficient is rounded, the rounding error is spread evenly across all 10 ms. Steady sounds may mask that noise, but in a quiet frame that ends with a transient, the noise arrives before the sound does, a faint smear ahead of the hit. This “pre-echo” is the smearing often heard on sharp percussion like cymbals and rim shots. Transform codecs can counter it because time and frequency are two views of the same information, and anything concentrated in one is spread out as a pattern in the other. A drum hit occupying a few milliseconds of a frame appears in the frequency domain as a pattern running across all coefficients, and the shape of that pattern is the shape of the hit in time. LC3’s Temporal Noise Shaping (TNS), applied after spectral shaping and when a frame will benefit from it, can use this.

Measure the pattern. The encoder finds a short recipe, eight numbers, by which each coefficient can be predicted from the few below it. The eight numbers travel with the data packet. They are, in effect, a compact description of the frame’s loudness over time.

Filter the pattern out, then round. Before rounding coefficients to fit within the bit budget, the encoder replaces each coefficient with only the part the recipe could not predict, eliminating that pattern. The rounding error is left flat across the frame, both in time and frequency.

Filter the pattern back in. The decoder applies the exact inverse of step 2, and the signal returns intact. The rounding error, which entered between the two filters, gets the pattern stamped on it also. A pattern in frequency is a shape in time, so the noise now rises and falls with the frame’s loudness, landing at and after the hit where the sound masks it. In frequency, nothing has moved.

Filling the Gaps

When a frame goes missing, the PLC algorithm kicks in. Keeping LC3’s promise of low complexity, it simply replays the last good frame’s spectrum. Every coefficient keeps its magnitude, so the overall shape of the sound carries through, but with two modifications. First, the polarity of each coefficient is flipped at random. This computationally cheap method scrambles the fine time-domain structure so that repeated frames do not create a 100 Hz buzz (one repeated frame every 10 ms is a 100 Hz pattern). Second, the level holds at full volume for the first three lost packets, 30 milliseconds, then steps down, slowly at first and then more quickly. A brief dropout is patched at full volume while a sustained one fades to silence in well under a second. When packets return, the next good frame simply decodes, and the codec’s overlapping transform window essentially creates a 2.5 ms fade-in.

PLC often works transparently when the sound is roughly steady, a held vowel or a sustained chord, for instance, or when the passage is already noise-like. When the missing packet was during a moment of change, a consonant landing or a drum hit, there may be nothing steady to carry forward; the repair is more audible. Occasional losses are neatly obscured while longer bursts during complex passages are not. Many codecs include far more sophisticated PLC, and LC3’s specification allows better schemes too. What it defines for Auracast™ is this deliberately lightweight reference method; manufacturers may implement a more sophisticated one.

Targeted Quality

LC3 can serve a wide range of quality needs with bitrates from 16 to 320 kbps and sample rates from 8 kHz to 48 kHz. Even high-resolution audio is supported by an available LC3plus extension of the codec. So while Bluetooth® LE Audio can carry audiophile-quality streams, Auracast™ curates a small subset of options. There are two quality tiers available. Standard Quality, which every Auracast™ device must support, uses 16 or 24 kHz sample rates. High Quality, which is optional, uses 48 kHz. Our example, 24 kHz at 48 kbps, is Standard Quality.

For assistive listening, Standard Quality is well targeted. A 24 kHz sample rate carries audio up to 12 kHz. That may seem modest, but estimating in 2026 from market share data and device model specifications, over half of hearing aids process audio at a 20 kHz sample rate, only 10 kHz of audio bandwidth, and only the highest-priced units, roughly the top quarter of the market, operate at 33.1 kHz. Speech intelligibility is almost entirely determined below 8 kHz, and 12 kHz exceeds the typical target devices’ capabilities. Full-range sample rates are worthwhile for the wider consumer audio market, but that richer stream is not free. More samples and bits mean larger packets, requiring more transmit time and power consumption. That means higher odds of interference and less time to repeat the packet or coexist with other Auracast™ broadcasts. Quality and resilience draw from the same airtime budget, and choosing between them is a design decision we’ll discuss in detail later in the series.

An interactive demonstration of Auracast™ broadcast audio: the original recording beside the same audio encoded live through the LC3 codec at both broadcast quality tiers, with adjustable packet loss and concealment.

The Bluetooth® word mark and logos are registered trademarks owned by Bluetooth SIG, Inc. The Auracast™ word mark and logos are trademarks owned by Bluetooth SIG, Inc. Any use of such marks by Listen Technologies Corporation is under license. Other trademarks and trade names are those of their respective owners.

Choose a clip or upload your own to hear Auracast™. You can also add simulated packet loss to hear how PLC works on different kinds of content and at different loss rates and patterns.

Takeaway

LC3’s design combined with carefully curated encoding profiles provides a foundation for Auracast’s success. Other codecs may offer more sophisticated PLC approaches, more complex perceptual compression schemes, and more adaptive structures. But LC3 is especially optimized for efficiency and low decoding burden, meeting the capabilities of hearing aids and earbuds, while operating as a true broadcast for Auracast™. Each data packet is independent, consistently structured, and compact in time and data payload. That keeps radio use low, conserving power and reducing the odds of interference. And when conditions do result in lost audio, the gap can often be smoothed over with no collateral damage to surrounding audio frames. Further, the radio scheme itself keeps the system lean, relying on statistical tactics rather than extra coded bits to get packets through. Those tactics and design choices are the subjects of the next two articles.