The Three Things Broadcast Needs to Do

Broadcast in LE Audio is split into three separate functions. Different devices implement different subsets of these:

In most real products all three happen together, but the specs keep them separate so each device only has to implement what it needs. A PA amplifier in an auditorium only needs the Transmit function. A hearing aid only needs the Receive function. A phone typically handles all three.

Setting Up a Broadcast Source

A Broadcast Source is the device that puts audio on air. A TV, a phone sharing audio, or a PA system all fit this role. Unlike a unicast Central device, the Broadcast Source does not need any receivers to be present. It just transmits. The Host application inside the device gives the Controller all the configuration it needs, and the Controller handles the rest.

State Machine — Three States

Transitions between states use HCI commands. Unlike unicast (where both sides negotiate), the Broadcast Source does all of this unilaterally — no handshakes with any receiver.

BAP defines six procedures for these transitions (configuration, establishment, disable, metadata update, release, reconfiguration). CAP simplifies them into five grouped procedures: Broadcast Audio Start, Update, Stop, Reception Start, and Reception Stop.

BASE — What the Receiver Reads to Know What Is Available

The BASE (Basic Audio Stream Endpoint) is a data structure packed into the Periodic Advertisement by the Broadcast Source. Every receiver reads the BASE to find out: how many audio streams are available, what codec is used, what quality, and what the content is (music, speech, which channel, which language, etc.).

BASE has three nested levels:

The rule for which level to use:

• Different languages or different parental ratings → separate subgroups (Level 2 entries). There is no other way to express this difference.
• Different audio quality of the same content → separate BIS entries at Level 3 within the same subgroup (e.g., one BIS at 48 kHz, one at 24 kHz).
• Typical stereo stream → one subgroup, two BISes (Left at index 1, Right at index 2). That is all most real products need.

BASE Parameters Table

Creating the BIG — LE_Create_BIG HCI Command

Once the BASE is assembled, the Host sends LE_Create_BIG to the Controller. This command schedules all the BIS channels and starts the isochronous broadcast. The key parameters:

How the Advertising Chain Works

A Broadcast Source runs three layers of advertising simultaneously. A receiver scans through all three layers to get everything it needs before locking on to the audio:

BlueZ Code: Creating a BIG Using ISO Sockets

Linux kernel 5.14+ supports Broadcast Isochronous Streams via ISO sockets in BlueZ. A connect() call on a bound ISO socket triggers LE_Create_BIG inside the kernel automatically:

/*
 * broadcast_source.c
 * Minimal Broadcast Source: creates a BIG with one BIS using BlueZ ISO socket API.
 * Build: gcc -o bcast_src broadcast_source.c -lbluetooth
 * Run as root: ./bcast_src
 */

#include <stdio.h>
#include <stdint.h>
#include <string.h>
#include <unistd.h>
#include <sys/socket.h>
#include <bluetooth/bluetooth.h>
#include <bluetooth/iso.h>

/* LC3 at 16 kHz, 10 ms frame, 32 kbps = 40 bytes per SDU */
#define LC3_SDU_SIZE   40
#define SDU_INTERVAL   10000   /* 10 ms in microseconds */

int main(void)
{
    int sk, ret;
    struct sockaddr_iso src = {0}, dst = {0};
    struct bt_iso_qos    qos = {0};
    uint8_t              frame[LC3_SDU_SIZE] = {0};

    /* 1. Create an ISO socket for BIS (broadcast) */
    sk = socket(PF_BLUETOOTH, SOCK_SEQPACKET, BTPROTO_ISO);
    if (sk < 0) { perror("socket"); return 1; }

    /* 2. Bind to default local adapter */
    src.iso_family      = AF_BLUETOOTH;
    src.iso_bdaddr_type = BDADDR_LE_PUBLIC;
    bacpy(&src.iso_bdaddr, BDADDR_ANY);

    ret = bind(sk, (struct sockaddr *)&src, sizeof(src));
    if (ret < 0) { perror("bind"); goto fail; }

    /* 3. Set BIG / BIS QoS parameters */
    qos.bcast.big           = BT_ISO_QOS_BIG_UNSET; /* kernel assigns */
    qos.bcast.bis           = BT_ISO_QOS_BIS_UNSET; /* kernel assigns */
    qos.bcast.packing       = 0x00;  /* Sequential */
    qos.bcast.framing       = 0x00;  /* Unframed */
    qos.bcast.encryption    = 0x00;  /* No encryption */
    memset(qos.bcast.bcode, 0, sizeof(qos.bcast.bcode));

    /* TX path parameters (LE Audio 16_2 preset) */
    qos.bcast.out.phy      = 0x02;        /* 2 Mbps */
    qos.bcast.out.sdu      = LC3_SDU_SIZE;
    qos.bcast.out.interval = SDU_INTERVAL;
    qos.bcast.out.latency  = 10;          /* ms */
    qos.bcast.out.rtn      = 2;           /* retransmissions */

    ret = setsockopt(sk, SOL_BLUETOOTH, BT_ISO_QOS, &qos, sizeof(qos));
    if (ret < 0) { perror("setsockopt BT_ISO_QOS"); goto fail; }

    /* 4. Connect: triggers LE_Create_BIG inside BlueZ kernel stack.
     *    iso_bdaddr_type = BDADDR_BREDR signals broadcast mode.
     *    iso_num_bis / iso_bis[] choose which BIS indices to create. */
    dst.iso_family      = AF_BLUETOOTH;
    dst.iso_bdaddr_type = BDADDR_BREDR;  /* broadcast flag */
    bacpy(&dst.iso_bdaddr, BDADDR_ANY);
    dst.iso_bc_sid      = 0x00;
    dst.iso_num_bis     = 1;
    dst.iso_bis[0]      = 0x01;          /* BIS index 1 (Left channel) */

    ret = connect(sk, (struct sockaddr *)&dst, sizeof(dst));
    if (ret < 0) { perror("connect (BIG create)"); goto fail; }

    printf("BIG created — sending audio frames\n");

    /* 5. Write LC3-encoded audio frames (here we send silence) */
    for (int i = 0; i < 500; i++) {        /* 500 frames = 5 seconds */
        /* In a real application: lc3_encode(pcm_buf, frame, LC3_SDU_SIZE) */
        ret = write(sk, frame, LC3_SDU_SIZE);
        if (ret < 0) { perror("write"); break; }
        usleep(SDU_INTERVAL);               /* pace to SDU interval */
    }

    printf("Done — releasing BIG\n");
    close(sk);
    return 0;

fail:
    close(sk);
    return 1;
}

Receiving a Broadcast Audio Stream

A Broadcast Sink scans for Extended Advertisements that carry the Broadcast Audio Announcement Service UUID. When it finds one it reads through the advertising chain, gets the BASE and BIGInfo from the Periodic Advertisement, picks the right BIS, and locks on.

The Four-Step Reception Flow

BlueZ Code: Scanning and Syncing to a BIS

/*
 * broadcast_sink.c
 * Connects to a known Broadcast Source and receives BIS audio via ISO sockets.
 * BlueZ kernel ISO socket API (kernel 5.14+).
 * Build: gcc -o bcast_sink broadcast_sink.c -lbluetooth
 */

#include <stdio.h>
#include <stdint.h>
#include <string.h>
#include <unistd.h>
#include <sys/socket.h>
#include <bluetooth/bluetooth.h>
#include <bluetooth/iso.h>

#define MAX_SDU 200

int main(void)
{
    int sk, ret;
    struct sockaddr_iso src = {0}, bsrc = {0};
    uint8_t  buf[MAX_SDU];
    ssize_t  n;

    /* 1. Open ISO socket */
    sk = socket(PF_BLUETOOTH, SOCK_SEQPACKET, BTPROTO_ISO);
    if (sk < 0) { perror("socket"); return 1; }

    /* 2. Bind to local adapter */
    src.iso_family      = AF_BLUETOOTH;
    src.iso_bdaddr_type = BDADDR_LE_PUBLIC;
    bacpy(&src.iso_bdaddr, BDADDR_ANY);

    ret = bind(sk, (struct sockaddr *)&src, sizeof(src));
    if (ret < 0) { perror("bind"); goto fail; }

    /*
     * 3. Connect to the Broadcast Source.
     *    iso_bdaddr       = address of the Broadcast Source device
     *    iso_bdaddr_type  = BDADDR_LE_PUBLIC or BDADDR_LE_RANDOM
     *    iso_bc_sid       = SID from ADV_EXT_IND (Advertising Set ID)
     *    iso_num_bis      = how many BIS we want to receive
     *    iso_bis[]        = BIS index values from the BASE
     *
     * The kernel handles PA sync and BIG sync internally.
     * On success, the socket is ready to receive audio frames.
     */
    bsrc.iso_family      = AF_BLUETOOTH;
    bsrc.iso_bdaddr_type = BDADDR_LE_PUBLIC;
    str2ba("AA:BB:CC:DD:EE:FF", &bsrc.iso_bdaddr); /* source address */

    bsrc.iso_bc_sid    = 0x00;  /* SID from the primary advertisement */
    bsrc.iso_num_bis   = 2;     /* receive stereo: Left + Right */
    bsrc.iso_bis[0]    = 0x01;  /* BIS index 1 = Left channel */
    bsrc.iso_bis[1]    = 0x02;  /* BIS index 2 = Right channel */

    ret = connect(sk, (struct sockaddr *)&bsrc, sizeof(bsrc));
    if (ret < 0) { perror("connect (BIG sync)"); goto fail; }

    printf("Synced to BIG — receiving audio\n");

    /* 4. Read incoming LC3 frames and pass to decoder */
    while ((n = read(sk, buf, sizeof(buf))) > 0) {
        /*
         * Each read() returns one SDU (one LC3 frame per BIS).
         * Pass to LC3 decoder:
         *   lc3_decode(decoder, buf, n, pcm_out, stride);
         * Then write pcm_out to ALSA / audio pipeline.
         */
        printf("Rx %zd bytes | pass to LC3 decoder\n", n);
    }

    close(sk);
    return 0;

fail:
    close(sk);
    return 1;
}

BASS — Broadcast Audio Scan Service

A Broadcast Sink can find and receive streams on its own — but that is not a good user experience. A small earbud with no screen needs to independently pick from potentially dozens of broadcast streams nearby. That is impractical. BASS solves this.

BASS is a GATT service that lives inside the Broadcast Sink (the Acceptor). It exposes the Sink’s current state — what streams it knows about, which one it is receiving, whether it needs an encryption key — so a separate device (a phone, a remote, a smartwatch acting as a Commander) can read and control it over a regular ACL connection.

The Two BASS Characteristics

Control Point Operation Codes

BIS_Sync — The Most Important Field

BIS_Sync is a 4-byte (32-bit) bitmap sent from the Commander to the Acceptor in the Add Source or Modify Source operations. Each bit position corresponds to a BIS index:

Broadcast Receive State — What the Acceptor Reports Back

Commanders — The Smart Remote for Broadcast

Without a Commander, a user with two earbuds would have to manually navigate each earbud’s minimal interface to select a stream, and handling encrypted streams would be nearly impossible. A Commander solves this by acting as a central control point — like a smart TV remote that also knows how to find radio stations and quietly pass the decryption keys to your earbuds.

Scan Delegator — How the Acceptor Solicits Help

The Scan Delegator role lives inside the Broadcast Sink. Its only job is to find Broadcast Assistants and hand them the scanning work. It does this by sending a Solicitation Request — an Extended Advertisement containing the BASS Service UUID. Any Broadcast Assistant that sees it can connect and take over.

Remote Broadcast Scanning — The Full Setup Flow

A Broadcast Assistant can also use PAST (Periodic Advertising Sync Transfer) to hand the PA sync directly to each earbud, instead of making the earbud scan for the periodic advertisement itself. This is faster and more power-efficient — the process is called Scan Offloading.

Broadcast_Codes — Encrypted Private Streams

A Broadcast Source can encrypt its audio using a 16-byte Broadcast_Code. Without this key, a receiver can lock on to the BIG but cannot decode the audio — it hears nothing. This creates a software boundary around the broadcast: only people or devices with the code can listen.

Encryption lifetimes vary widely by use case:

How the Code Gets to the Acceptor

When an Acceptor locks on to an encrypted BIG, it cannot decrypt the audio. It sets BIG_Encryption = 0x01 in its Broadcast Receive State and sends a notification to all connected Broadcast Assistants — essentially asking “does anyone have the key?”

Any Assistant that has the code can respond by writing opcode 0x04 (Set Broadcast Code) to the Scan Control Point with the 16-byte key and the Source_ID. If the Acceptor previously had a wrong key, it sets BIG_Encryption = 0x03 and includes the bad key in the Bad_Code field so Assistants do not waste time re-sending the same wrong key.

Presentation Delay in Broadcast

In unicast, both sides negotiate the Presentation Delay. In broadcast, the Source picks a value and puts it in the BASE. Receivers must use it or fall back to a default. This matters because left and right earbuds need to render audio at exactly the same moment.

Handover Between Unicast and Broadcast

CAP defines two procedures to switch the same audio content between unicast and broadcast without an audible gap. A real-world example: you are listening to TV over a unicast connection, then a friend arrives and you want to share the audio. The TV switches to broadcast mode. Both of you now receive over BIS channels.

Two important rules govern this handover:

• The Streaming Context Types and CCID list from the original unicast stream carry over to the broadcast stream. The original listener keeps full playback control (pause, fast-forward, volume) because the ACL link stays up.
• Friends who join the broadcast only get the audio. They do not inherit control because they never had the unicast connection.

Summary — Key Terms at a Glance