There are two flavours of Isochronous Streams in BLE Audio. Choosing which one to use depends on your use case:

Everyday analogy: CIS is like a phone call — both sides confirm the conversation. BIS is like an FM radio station — it just transmits and anyone with a radio can listen.

BLE Audio has a strict hierarchy. One device is always in charge of timing and scheduling — everything else follows its lead.

Important thing to remember: Either device can be the audio source or sink. Your earbud’s microphone sends voice data back to the phone — the earbud is still the Acceptor, but it generates audio data. The Initiator tells it exactly when to send that data.

As we go up the protocol stack, the names change:

The LC3 codec (mandatory for BLE Audio) works in 10ms frames — it grabs 10ms of audio, compresses it, and hands it off to Bluetooth. Bluetooth transmits it in a fixed window called the Isochronous Interval.

Wireless environments have interference. What if one transmission gets blocked by Wi-Fi? BLE Audio’s answer: retry the same packet multiple times within one ISO Interval, each time on a different radio channel. Each retry slot is called a Subevent.

The inter-frame gap between Subevents is always 150 microseconds — just enough time for the radio to switch channels. The BLE Core 5.2 spec introduced an improved channel selection algorithm that decides which frequency to use for each Subevent.

The CIE Bit — Saving Battery

Once the Acceptor successfully receives the packet and sends an Ack, the Initiator sets the CIE (Close Isochronous Event) bit in its next transmission. This tells the Acceptor: “you already got the packet — go to sleep until the next ISO Interval.” No need to stay awake for Subevents 3 and 4.

The freed Subevents can be used by the chip for Wi-Fi transmissions or other Bluetooth connections — very important since phones share one antenna for both Wi-Fi and Bluetooth.

Every packet transmitted over the air has this overall structure:

The ISO PDU’s header contains control bits that manage the flow of data. For a CIS, these are:

These three parameters control how hard the system tries to get each audio packet through. You do not set these directly — you give the Controller higher-level hints (latency, SDU size) and it calculates the best NSE/FT/BN values automatically.

NSE=4, FT=1 Example — Four Tries Per Interval

FT=3 — More Intervals = More Chances (But More Latency)

With FT=3, the packet P0 can retry across 3 ISO Intervals (30ms total) before being flushed. This helps in noisy environments but adds up to 30ms of latency. The risk with FT alone is that a struggling packet (P0) can hog all Subevents, blocking P1 and P2 from getting airtime.

BN=2 — Fairness Fix (Share Subevents Between Two Packets)

The solution to the “hogging” problem is Burst Number. With BN=2, the ISO Interval is doubled to 20ms, so two packets (P0 and P1) are loaded into each interval. The 4 Subevents are shared between them — P0 can’t consume all 4. This is fairer but doubles the interval length.

For a phone call you need audio flowing both ways at the same time. BLE Audio is clever about this: instead of creating a second CIS, the Acceptor’s acknowledgement packet carries the microphone audio back to the Initiator. One CIS, two audio streams.

The microphone data from the left earbud travels inside its acknowledgement packet back to the phone. The right earbud has no microphone, so it sends a plain acknowledgement with NPI=1 (null payload, no audio data).

Rules for bidirectional CIS (important for implementation):

• Only the Initiator sets the CIE bit — and only after both directions are acknowledged
• FT and BN can differ for each direction (uplink voice vs downlink music may have different needs)
• ISO Interval and NSE must be the same for both directions
• If the Initiator has had its packet ACKed but hasn’t received the Acceptor’s data yet, it must keep sending null PDUs to give the Acceptor chances to retransmit

When your phone streams audio to both earbuds simultaneously, it creates two CIS streams inside one CIG. These can be scheduled in two ways:

How Left and Right Earbuds Stay in Sync

Left and right earbuds don’t talk to each other — but they must play audio at precisely the same moment. The solution is the CIG synchronisation point and CIS Sync Delays:

The Presentation Delay (set by the Basic Audio Profile, BAP) is an extra buffer added after the Sync Point. Both earbuds wait exactly this long before playing — even if one received its packet earlier than the other. This is why BLE Audio earbuds achieve microsecond-level synchronisation without knowing each other exists.

The Bluetooth Host (your app code, via BlueZ) sends HCI commands to the Controller chip to set up streams. The CIG goes through these states:

BlueZ 5.64+ exposes BLE Audio via ISO sockets. They look and feel like regular BSD sockets, but under the hood they trigger all the HCI commands we just discussed. Here’s a step-by-step guide:

Step 1 — Create the ISO Socket

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/socket.h>
#include <bluetooth/bluetooth.h>
#include <bluetooth/iso.h>    /* ISO socket support — BlueZ 5.64+ */

int main(void)
{
    int sock_fd;

    /*
     * PF_BLUETOOTH = Bluetooth address family
     * SOCK_SEQPACKET = message-oriented, ordered, each send() = one SDU
     * BTPROTO_ISO   = ISO transport protocol (new in BlueZ 5.64)
     */
    sock_fd = socket(PF_BLUETOOTH, SOCK_SEQPACKET, BTPROTO_ISO);
    if (sock_fd < 0) {
        perror("socket() failed - check BlueZ version >= 5.64");
        return -1;
    }
    printf("ISO socket created, fd=%d\n", sock_fd);
    return 0;
}

Step 2 — Bind to Local Adapter

/* sockaddr_iso is the BLE Audio equivalent of sockaddr_in */
struct sockaddr_iso local_addr;
memset(&local_addr, 0, sizeof(local_addr));

local_addr.iso_family      = AF_BLUETOOTH;
local_addr.iso_bdaddr      = *BDADDR_ANY;        /* Use default HCI adapter */
local_addr.iso_bdaddr_type = BDADDR_LE_PUBLIC;

if (bind(sock_fd, (struct sockaddr *)&local_addr, sizeof(local_addr)) < 0) {
    perror("bind() failed");
    close(sock_fd);
    return -1;
}
printf("Bound to local BLE adapter\n");

Step 3 — Set QoS Parameters

This is where you specify latency and SDU size. BlueZ passes these to the Controller via LE_Set_CIG_Parameters — the Controller then calculates NSE, FT, and BN internally.

struct bt_iso_qos qos;
memset(&qos, 0, sizeof(qos));

/*
 * BT_ISO_QOS_CIG_UNSET and BT_ISO_QOS_CIS_UNSET mean:
 * "let the Controller auto-assign IDs"
 */
qos.ucast.cig = BT_ISO_QOS_CIG_UNSET;
qos.ucast.cis = BT_ISO_QOS_CIS_UNSET;

/* ----- OUTGOING: phone -> earbud (music/audio) ----- */
qos.ucast.out.interval = 10000;  /* SDU interval in microseconds (= 10ms) */
qos.ucast.out.latency  = 10;     /* Maximum transport latency in ms */
qos.ucast.out.sdu      = 100;    /* Maximum SDU size in bytes (LC3 frame) */
qos.ucast.out.phy      = 0x02;   /* PHY: 0x01=1M, 0x02=2M (preferred for audio) */
qos.ucast.out.rtn      = 2;      /* Retransmission number hint (Controller decides FT/NSE) */

/* ----- INCOMING: earbud mic -> phone (voice) ----- */
/* Set sdu=0 for unidirectional (music-only, no mic) */
qos.ucast.in.interval  = 10000;
qos.ucast.in.latency   = 10;
qos.ucast.in.sdu       = 0;      /* 0 = no uplink audio (unidirectional) */
qos.ucast.in.phy       = 0x02;
qos.ucast.in.rtn       = 2;

if (setsockopt(sock_fd, SOL_BLUETOOTH, BT_ISO_QOS, &qos, sizeof(qos)) < 0) {
    perror("setsockopt(BT_ISO_QOS) failed");
    return -1;
}
printf("QoS set: 10ms interval, 10ms latency, 100-byte SDU, 2M PHY\n");

Step 4 — Connect to the Earbud (Triggers LE_Create_CIS)

bdaddr_t earbud_bdaddr;
/* Replace with your earbud's Bluetooth address */
str2ba("AA:BB:CC:DD:EE:FF", &earbud_bdaddr);

struct sockaddr_iso remote_addr;
memset(&remote_addr, 0, sizeof(remote_addr));
remote_addr.iso_family      = AF_BLUETOOTH;
remote_addr.iso_bdaddr      = earbud_bdaddr;
remote_addr.iso_bdaddr_type = BDADDR_LE_PUBLIC;

/*
 * connect() triggers:
 *   1. LE_Set_CIG_Parameters HCI command (Controller calculates NSE/FT/BN)
 *   2. LE_Create_CIS HCI command (opens the audio stream)
 *   3. Earbud receives HCI LE CIS Request and accepts it
 *   4. Both sides get HCI LE CIS Established event
 */
if (connect(sock_fd, (struct sockaddr *)&remote_addr, sizeof(remote_addr)) < 0) {
    perror("connect() failed - is device paired and in range?");
    return -1;
}
printf("CIS established! Audio stream is live.\n");

Step 5 — Send Audio SDUs (10ms loop)

uint8_t audio_sdu[100];  /* One 10ms LC3-encoded audio frame */

/*
 * In production: replace with LC3 encoder output.
 * Each send() delivers exactly one SDU (one ISO Interval of audio).
 * BlueZ handles fragmenting it into PDUs, NSE retransmissions, etc.
 */
while (1) {
    /* TODO: fill audio_sdu with actual LC3-encoded audio */
    memset(audio_sdu, 0x55, sizeof(audio_sdu)); /* silence placeholder */

    ssize_t written = send(sock_fd, audio_sdu, sizeof(audio_sdu), 0);
    if (written < 0) {
        perror("send() failed");
        break;
    }

    /* Sleep for one ISO Interval (10ms = 10000 microseconds) */
    usleep(10000);
}

close(sock_fd);
return 0;

BIS is the broadcast version. The transmitter just sends continuously — no pairing, no acknowledgements, no per-device overhead. Any device within range can tune in.

BIS Robustness — Group Count, IRC, and PTO

Since there are no ACKs, BIS uses different tricks to ensure delivery:

With no connection, how does an earbud know where to tune in? The broadcaster publishes a multi-hop chain of advertising packets:

What’s in BIGInfo?

BIGInfo (inside the ACAD field) gives the receiver everything it needs to decode the timing and structure of the BIG. Key fields include ISO_Interval, Sub_Interval, BIS_Spacing, NSE, BN, PTO, IRC, Max_PDU, Channel Map, and PHY. For encrypted broadcasts, it also contains GIV and GSKD (encryption keys derivation info).

What’s in BASE? The 3-Level Structure

Setting up a BIG in BlueZ is simpler than CIS because there’s no per-device pairing. You bind to broadcast addresses and start transmitting. BlueZ handles the Extended Advertising chain automatically.

Broadcaster — Create a BIG and Start Sending Audio

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

int main(void)
{
    int bc_fd;
    bc_fd = socket(PF_BLUETOOTH, SOCK_SEQPACKET, BTPROTO_ISO);

    /* Bind to local adapter */
    struct sockaddr_iso local = {
        .iso_family      = AF_BLUETOOTH,
        .iso_bdaddr      = *BDADDR_ANY,
        .iso_bdaddr_type = BDADDR_LE_PUBLIC,
    };
    bind(bc_fd, (struct sockaddr *)&local, sizeof(local));

    /* Configure BIG QoS */
    struct bt_iso_qos qos;
    memset(&qos, 0, sizeof(qos));

    qos.bcast.big      = BT_ISO_QOS_BIG_UNSET;  /* Auto-assign BIG ID */
    qos.bcast.bis      = BT_ISO_QOS_BIS_UNSET;  /* Auto-assign BIS ID */
    qos.bcast.packing  = 0x00;  /* Sequential packing of BISes */
    qos.bcast.framing  = 0x00;  /* Unframed (10ms codec = 10ms ISO Interval) */
    qos.bcast.encryption = 0x00; /* No encryption — public broadcast */

    /* Audio stream parameters */
    qos.bcast.out.interval = 10000;  /* 10ms */
    qos.bcast.out.latency  = 10;
    qos.bcast.out.sdu      = 100;
    qos.bcast.out.phy      = 0x02;   /* 2M PHY */
    qos.bcast.out.rtn      = 4;      /* More retransmissions — no ACKs in BIS */

    setsockopt(bc_fd, SOL_BLUETOOTH, BT_ISO_QOS, &qos, sizeof(qos));

    /*
     * connect() to BDADDR_ANY = start broadcasting
     * BlueZ automatically sets up:
     *   - ADV_EXT_IND on primary channels 37/38/39
     *   - AUX_ADV_IND on secondary channels with Broadcast_ID
     *   - Periodic Advertising train with BIGInfo and BASE
     *   - Then starts the BIG itself
     */
    struct sockaddr_iso dst = {
        .iso_family      = AF_BLUETOOTH,
        .iso_bdaddr      = *BDADDR_ANY,
        .iso_bdaddr_type = BDADDR_LE_PUBLIC,
    };
    if (connect(bc_fd, (struct sockaddr *)&dst, sizeof(dst)) < 0) {
        perror("broadcast connect() failed");
        return -1;
    }
    printf("BIG started! Broadcasting audio on 10ms intervals...\n");

    /* Send audio every 10ms */
    uint8_t audio_buf[100];
    while (1) {
        /* In real code: fill with LC3-encoded audio */
        memset(audio_buf, 0xAB, sizeof(audio_buf));
        send(bc_fd, audio_buf, sizeof(audio_buf), 0);
        usleep(10000); /* 10ms = 10000 microseconds */
    }

    close(bc_fd);
    return 0;
}

Broadcast Sink — Sync to a BIG and Receive Audio

int sink_fd;
sink_fd = socket(PF_BLUETOOTH, SOCK_SEQPACKET, BTPROTO_ISO);

/*
 * To sync to a specific broadcaster:
 * 1. Scan to find the ADV_EXT_IND and get the broadcaster's address
 * 2. Read AUX_ADV_IND to get the Broadcast_ID
 * 3. Sync to the Periodic Advertising train to get BIGInfo and BASE
 * 4. Use the BIS_Index from BASE to choose which BIS to receive
 * BlueZ tools like btmon and btvirt can help with testing
 */

/* Broadcaster's BT address (from scanning AUX_ADV_IND) */
bdaddr_t bc_addr;
str2ba("11:22:33:44:55:66", &bc_addr); /* broadcaster's address */

struct sockaddr_iso sink_addr = {
    .iso_family      = AF_BLUETOOTH,
    .iso_bdaddr      = bc_addr,
    .iso_bdaddr_type = BDADDR_LE_PUBLIC,
    .iso_bc_sid      = 0x00,  /* SID from ADV_EXT_IND */
};

/* Configure sync timeout */
struct bt_iso_qos sink_qos;
memset(&sink_qos, 0, sizeof(sink_qos));
sink_qos.bcast.sync_timeout = 0x4000; /* sync timeout in 10ms units */
sink_qos.bcast.mse          = 0x00;   /* max subevents to scan */

setsockopt(sink_fd, SOL_BLUETOOTH, BT_ISO_QOS, &sink_qos, sizeof(sink_qos));

/*
 * connect() = start syncing to the BIG
 * BlueZ reads the Periodic Advertising, parses BIGInfo,
 * and starts receiving audio packets
 */
if (connect(sink_fd, (struct sockaddr *)&sink_addr, sizeof(sink_addr)) < 0) {
    perror("sync to BIG failed - is broadcaster advertising?");
    return -1;
}
printf("Synced to BIG! Receiving audio...\n");

/* Receive audio SDUs */
uint8_t recv_buf[256];
while (1) {
    ssize_t len = recv(sink_fd, recv_buf, sizeof(recv_buf), 0);
    if (len > 0) {
        /* Each recv() gives one complete SDU = one 10ms audio frame */
        printf("Received %zd bytes of audio\n", len);
        /* In real code: pass to LC3 decoder, then to audio output */
    }
}

close(sink_fd);

ISOAL solves a very specific problem: what if the codec frame length and the ISO Interval don’t match? This is handled entirely inside the Bluetooth chip — you never write ISOAL code — but understanding it helps when debugging audio glitches.

The 7.5ms mismatch occurs because classic Bluetooth devices (old mice, keyboards) use a 7.5ms radio interval. A dual-mode device (phone) that supports both Classic and LE Audio must align its timing — ISOAL handles the conversion transparently.

In the framed case, each SDU segment gets a Time_Offset field which tells the receiver exactly when the original SDU’s audio should be played relative to the Anchor Point — so even though the audio data is split across multiple PDUs, the receiver reassembles it and plays it at exactly the right time.