LC3 Encoding in Code (BlueZ / liblc3 usage)

#include <lc3.h>   /* Bluetooth SIG reference LC3 library */
#include <stdint.h>

#define SAMPLE_RATE   48000
#define FRAME_US      10000   /* 10 ms in microseconds */
#define BITRATE       80000   /* 80 kbps */
#define CHANNELS      1       /* mono (one earbud) */

/* Calculate derived values */
int frame_samples = lc3_frame_samples(FRAME_US, SAMPLE_RATE);
/* = 480 samples for 48 kHz / 10 ms */

int encoded_bytes  = lc3_frame_bytes(FRAME_US, BITRATE);
/* = 100 bytes for 80 kbps / 10 ms */

/* Allocate encoder — one per channel */
lc3_encoder_t encoder = lc3_setup_encoder(
    FRAME_US,     /* frame duration in µs: 7500 or 10000 */
    SAMPLE_RATE,  /* 8000 / 16000 / 24000 / 32000 / 44100 / 48000 */
    0,            /* hrmode: 0 = standard                */
    malloc(lc3_encoder_size(FRAME_US, SAMPLE_RATE))
);

/* Per-frame encode loop — called every 10 ms by your audio thread */
int16_t  pcm_buffer[480];      /* 10 ms of 48 kHz samples */
uint8_t  lc3_packet[100];      /* compressed output        */

/* Collect 480 samples from audio source (mic / file / ALSA) ... */

int ret = lc3_encode(
    encoder,
    LC3_PCM_FORMAT_S16,   /* 16-bit signed PCM */
    pcm_buffer,           /* input samples     */
    1,                    /* stride (1 = packed) */
    encoded_bytes,        /* target size in bytes */
    lc3_packet            /* output buffer       */
);

if (ret == 0) {
    /* Hand lc3_packet to BlueZ ISO socket for transmission */
    send(iso_sock_fd, lc3_packet, encoded_bytes, 0);
}

/* Note: lc3_packet has NO timestamp or sequence number.
 * The BLE Controller handles timing via the Isochronous Channel. */

6.1 The Decoder — Reverse Assembly Line

The decoder is essentially the encoder in reverse. It starts with the compressed bitstream and reconstructs the original audio waveform.

6.2 What Happens When a Packet is Lost? — PLC

Bluetooth shares the 2.4 GHz band with Wi-Fi, baby monitors, and countless other devices. Packets will get lost occasionally — especially outdoors where walls don’t reflect the signal.

When a packet is lost, the Controller sets a BFI flag (Bad Frame Indication). The decoder then runs PLC (Packet Loss Concealment) instead of decoding a real packet.

/* BlueZ / ISO socket receive loop with PLC handling */

uint8_t  recv_buf[200];
int16_t  pcm_out[480];       /* decoded 10 ms of audio */
uint8_t  bad_frame = 0;      /* BFI flag */

ssize_t bytes_received = recv(iso_sock_fd, recv_buf, sizeof(recv_buf), 0);

if (bytes_received <= 0) {
    /* Packet lost or socket error — trigger PLC */
    bad_frame = 1;
}

/* LC3 decode — pass bad_frame=1 to activate PLC internally */
int ret = lc3_decode(
    decoder,
    bad_frame ? NULL : recv_buf,  /* NULL triggers PLC */
    bad_frame ? 0    : bytes_received,
    LC3_PCM_FORMAT_S16,
    pcm_out,
    1                              /* stride */
);

/* pcm_out now has either real decoded audio or PLC-generated audio.
 * Feed it to ALSA / PulseAudio for playback at the Presentation Delay. */
write_to_alsa(pcm_out, 480);

Let’s trace exactly how the latency builds up end-to-end in a BLE Audio link. The key insight is that latency is not one big delay — it’s the sum of many small delays, each with a purpose.

7.1 The Synchronisation Reference Point — Why It’s Critical for Stereo

Imagine left and right earbuds each decoding at slightly different times. You’d hear stereo as slightly time-shifted — the music would feel “off”. The Synchronisation Reference Point is a fixed timestamp broadcast by the Initiator. All Acceptors start decoding at exactly this moment, ensuring left and right earbuds are perfectly synchronised.

7.2 Presentation Delay — The Buffer Before Rendering

BAP (Basic Audio Profile) requires every Audio Sink to support a Presentation Delay of 40 ms. This is not the default — it’s the minimum that must be in the supported range. Why 40 ms? It gives enough buffer time for:

• LC3 decoding (~2 ms)
• PLC if needed (~2 ms)
• Noise cancellation / speech enhancement algorithms (~5–30 ms)
• Synchronisation buffer between devices

High-end hearing aids can achieve Presentation Delay as low as 5 ms. TMAP and HAP profiles require support for 20 ms.

You never tweak the internals of LC3. As a BLE Audio developer, you configure four key parameters, and BAP defines 16 standard combinations to help interoperability.

QoS in BLE Audio is about answering: “How aggressively should we retransmit packets to avoid audio glitches, and what latency price are we willing to pay?”

BLE Audio uses Isochronous Channels to send audio. Each transmission window is called an Isochronous Interval (= frame duration = typically 10 ms). If a packet can be retransmitted multiple times within one interval, latency stays low. If retransmissions spill into the next interval (or the one after), latency grows by one frame per extra interval.

9.1 RTN — The Retransmission Number

The Host tells the Controller how many retransmissions to allow via the RTN (Retransmission Number) parameter. But RTN is only a hint — the Controller (hardware scheduler) can adjust this based on what else the chip is doing (e.g. Wi-Fi coexistence).

9.2 The 48_2_2 Example — Three Ways the Controller Can Schedule It

BAP provides a concrete example: the 48_2_2 High Reliability broadcast configuration (48 kHz, 10 ms, 100 bytes, RTN=4, max transport latency 65 ms). The Controller can implement this in three ways:

9.3 Airtime — The Scarce Resource

Airtime is like road space on a single-lane highway. Every packet occupies the road for a while. LC3 is already much better than SBC (roughly half the airtime for the same audio quality). But as you increase quality (48 kHz, high bitrate) and reliability (more retransmissions), airtime usage climbs fast:

Stereo means two audio channels (Left and Right). BLE Audio gives you flexibility in how to deliver those two channels. This is controlled by Channel Allocation and how many CISes (Connected Isochronous Streams) are established.

10.1 The Popular Case — Separate Earbuds

10.2 Broadcast for Multiple Languages

A cinema can broadcast audio in multiple languages simultaneously using BIS (Broadcast Isochronous Streams). Each language stream is a separate BIS. Audience members tune in to whichever BIS matches their preferred language — like selecting a radio channel.

This works at 24 kHz because each stereo stream uses ~30% airtime — two streams = 60%, leaving 40% for other uses. At 48 kHz, one stereo stream already uses 59% — there’s no room for a second language!

/* BlueZ: Setting up two CIS connections (Left + Right earbuds)
 * using the ISO socket API (BlueZ 5.65+)                        */

#include <bluetooth/bluetooth.h>
#include <bluetooth/iso.h>

struct bt_iso_qos qos = {
    .cig = BT_ISO_QOS_CIG_UNSET,
    .cis = BT_ISO_QOS_CIS_UNSET,
    .sdu        = 100,         /* 100 bytes per frame = 80 kbps @ 48kHz */
    .phy        = BT_ISO_PHY_2M,
    .rtn        = 2,           /* retransmission number (guidance to controller) */
    .latency    = 10,          /* max transport latency in ms */
    .interval   = 10000,       /* SDU interval = 10 ms in µs */
    .framing    = BT_ISO_FRAMING_UNFRAMED,
};

/* Create two ISO sockets — one for each earbud */
int left_sock  = socket(PF_BLUETOOTH, SOCK_SEQPACKET, BTPROTO_ISO);
int right_sock = socket(PF_BLUETOOTH, SOCK_SEQPACKET, BTPROTO_ISO);

/* Set QoS on each socket */
setsockopt(left_sock,  SOL_BLUETOOTH, BT_ISO_QOS, &qos, sizeof(qos));
setsockopt(right_sock, SOL_BLUETOOTH, BT_ISO_QOS, &qos, sizeof(qos));

/* Bind and connect to each earbud address... */
/* (bind/connect code omitted for brevity)   */

/* In the audio loop: encode LEFT channel, send on left_sock
 *                    encode RIGHT channel, send on right_sock
 *                    Both share the same CIG so they're synchronised */

lc3_encode(enc_left,  LC3_PCM_FORMAT_S16, left_pcm,  1, 100, left_pkt);
lc3_encode(enc_right, LC3_PCM_FORMAT_S16, right_pcm, 1, 100, right_pkt);

send(left_sock,  left_pkt,  100, 0);  /* sent on CIS for left earbud  */
send(right_sock, right_pkt, 100, 0);  /* sent on CIS for right earbud */

/* Both earbuds share the same CIG synchronisation reference point
 * so they render audio at exactly the same moment → perfect stereo */