Imagine you want to send a voice message over WhatsApp. You record 5 seconds of audio on your phone. Uncompressed, that raw audio would be a big chunk of data. But WhatsApp sends it in less than a second — that’s because it uses a codec. Codec = Coder + Decoder. The coder compresses audio; the decoder expands it back. Without compression you cannot retransmit a packet if it gets lost — there simply isn’t enough time.

1.1 From Analogue → Digital: PCM

Before codecs, audio was purely analogue (vinyl records, cassette tapes). If a vinyl record had a scratch, you heard a pop — no recovery possible. The first digital breakthrough was PCM (Pulse Code Modulation), used on CDs. PCM samples audio 44,100 times every second (44.1 kHz) and converts each sample to a number. The problem? No compression. 1 minute of CD-quality stereo audio = ~10 MB. That’s too big to send wirelessly in real time.

1.2 Perceptual Coding — Throw Away What You Can’t Hear

MP3 (and LC3) use a clever trick: perceptual coding (also called psychoacoustic modelling). The idea is simple — the human ear cannot hear everything, so why encode it?

Latency is the delay between a sound entering a microphone (or a file starting to play) and that sound coming out of the speaker. For wired headphones it’s essentially zero. For Bluetooth, it’s not.

2.1 The Three Parts of Latency

2.2 The Frame — The Root Cause of Encoding Delay

Perceptual coding needs to look at multiple consecutive audio samples to find patterns worth compressing. This collection of samples is called a frame. The codec must wait until the frame is complete before it can encode anything.

2.3 Why Does Latency Even Matter?

Before BLE Audio, Bluetooth had two audio profiles, each with its own codec:

3.1 CVSD — The Old Phone Codec

CVSD (Continuous Variable Slope Delta modulation) is one of the oldest voice codecs. It samples at 64,000 times/second but only stores the difference between consecutive samples (“did the sound go up or down?”). This makes it:

• • • • • • • • • • • • • • • • ✅ Frameless — no need to collect a full frame, so encoding starts immediately

• • • • • • • • • • • • • • • • ✅ Very low latency — great for phone calls

• • • • • • • • • • • • • • • • ❌ No compression — no room for retransmissions, so any packet lost = audio lost

• • • • • • • • • • • • • • • • ❌ Poor quality — only captures slope differences, not the full waveform

3.2 SBC — The Music Codec (A2DP)

SBC (Sub Band Coding) is a frame-based codec with basic psychoacoustic modelling. It produces good music quality but at a cost:

• • • • • • • • • • • • • • • • ❌ High latency (100–200 ms) because of large frames + retransmission buffers

• • • • • • • • • • • • • • • • ❌ Inefficient — packets are large, consume too much airtime, drain battery

• • • • • • • • • • • • • • • • ❌ Especially bad for hearing aids running on tiny zinc-air batteries — too much peak current

The problem: There’s a huge gap — no single codec covers everything. HFP is low-latency but poor quality. A2DP is high-quality but high-latency. What if you need both good quality and low latency — like a hearing aid listening to music in a noisy environment?

During the development of Bluetooth LE Audio, it became clear that neither CVSD nor SBC could meet the requirements for modern use cases. The Bluetooth SIG went on a “codec hunt” and the result was LC3 (Low Complexity Communication Codec).

4.1 What Was Wrong With SBC?

4.2 LC3 Key Benefits

4.3 LC3 Licence — Anyone Can Use It

LC3 is published under a RANDZ licence (Reasonable and Non-Discriminatory, Zero fee). This means anyone can write their own LC3 implementation and use it in a Bluetooth product — for free — as long as the product passes the Bluetooth Qualification process.

4.4 How This Looks in BlueZ Code

In BlueZ (the Linux Bluetooth stack), when setting up a BLE Audio stream, you configure LC3 parameters via the codec configuration. Here’s a simplified example of how codec settings appear in the D-Bus API:

/*
 * BlueZ BLE Audio – LC3 Codec Configuration Example
 *
 * When an Initiator (e.g. phone) sets up a CIS to an Acceptor
 * (e.g. earbud), it negotiates LC3 parameters.
 *
 * These map directly to the LC3 spec parameters:
 *  - Sampling_Frequency  → 0x03 = 16 kHz, 0x08 = 48 kHz, etc.
 *  - Frame_Duration      → 0x00 = 7.5 ms, 0x01 = 10 ms
 *  - Octets_per_Codec_Frame → payload size per channel
 */

/* LC3 Codec Configuration LTV (Length-Type-Value) structure
 * sent in HCI LE_Setup_ISO_Data_Path or via GATT ASE params */

struct lc3_codec_config {
    uint8_t  sampling_freq;     /* 0x03=16kHz, 0x05=24kHz,
                                   0x06=32kHz, 0x08=48kHz  */
    uint8_t  frame_duration;    /* 0x00=7.5ms, 0x01=10ms   */
    uint32_t audio_channel_alloc; /* Front Left=0x01, Right=0x02 */
    uint16_t octets_per_frame;  /* 20–400 bytes             */
    uint8_t  frames_per_sdu;    /* typically 1              */
};

/* Example: 48 kHz, 10 ms frame, 100 bytes/frame (80 kbps), stereo Left */
struct lc3_codec_config left_earbud_config = {
    .sampling_freq        = 0x08,   /* 48 kHz   */
    .frame_duration       = 0x01,   /* 10 ms    */
    .audio_channel_alloc  = 0x01,   /* Front Left */
    .octets_per_frame     = 100,    /* 80 kbps  */
    .frames_per_sdu       = 1,
};

/* Same for right earbud but channel = Front Right (0x02) */
struct lc3_codec_config right_earbud_config = {
    .sampling_freq        = 0x08,
    .frame_duration       = 0x01,
    .audio_channel_alloc  = 0x02,   /* Front Right */
    .octets_per_frame     = 100,
    .frames_per_sdu       = 1,
};

/*
 * The LC3 encode/decode itself is done by a library.
 * Pseudocode for encoding one frame:
 *
 *   lc3_encode(encoder_handle,
 *              pcm_input_buffer,   // 48000 * 10ms = 480 samples
 *              output_packet,      // compressed to 100 bytes
 *              100);               // target size in bytes
 *
 * The output_packet is then handed to BlueZ / HCI as the SDU
 * (Service Data Unit) for transmission on the ISO channel.
 */