Before diving into individual pieces, it helps to see the full picture. BLE Audio is not one protocol — it is a stack of profiles and services built on top of the Isochronous transport we studied in Part 1.

The key insight is this: GATT controls the setup (negotiating codec parameters, enabling ASEs), and ISO sockets carry the audio. They are separate paths — GATT uses the regular ACL link, while audio flows on the dedicated ISO link.

Before streaming any audio, the phone must know what the earbud is capable of. This discovery happens via the PACS GATT service running on the earbud. Think of PACS as the earbud’s “menu” — it lists every codec configuration it can handle.

What is a PAC Record?

Each PAC characteristic contains one or more PAC Records. Each record describes one supported codec configuration. A modern earbud might have 3-5 PAC records covering different sample rates and bitrates.

LTV Format — Length, Type, Value

The Codec_Specific_Capabilities field uses a compact LTV (Length-Type-Value) encoding. Each capability is listed as: 1 byte length, 1 byte type, N bytes of value. This is similar to TLV but the Length includes the Type byte.

/* Example: Decoding a PAC record's Codec_Specific_Capabilities in C */

/* Raw bytes from a Sink PAC characteristic */
uint8_t caps[] = {
    0x03, 0x01, 0x05, 0x00,  /* Supported Sampling Frequencies: 16kHz + 48kHz */
    0x02, 0x02, 0x03,        /* Supported Frame Durations: 7.5ms + 10ms       */
    0x02, 0x03, 0x01,        /* Supported Audio Channel Counts: 1 channel      */
    0x05, 0x04, 0x1E, 0x00, 0x78, 0x00, /* Min octets=30, Max octets=120      */
    0x02, 0x05, 0x01         /* Max Codec Frames per SDU: 1                    */
};

/* How to read it:
 * Byte 0: Length = 0x03 (meaning: type + 2 value bytes follow)
 * Byte 1: Type   = 0x01 (Supported_Sampling_Frequencies)
 * Byte 2-3: Value = 0x0005
 *   Bit 0 = 8kHz (not set)
 *   Bit 1 = 11.025kHz (not set)
 *   Bit 2 = 16kHz (set!) ← 0x0004 bit is bit 2
 *   ...
 *   Bit 8 = 48kHz (set!) ← 0x0100 not in 0x0005, wait...
 *
 * Actually 0x0005 = bits 0 and 2 set:
 *   bit 0 = 8000  Hz
 *   bit 2 = 16000 Hz
 * Typical earbud: 0x00FD = 8/16/24/32/44.1/48 kHz all supported
 */

/* Type values for Codec_Specific_Capabilities */
#define LC3_SUPPORTED_SAMPLING_FREQ   0x01
#define LC3_SUPPORTED_FRAME_DURATION  0x02
#define LC3_SUPPORTED_CHAN_COUNT      0x03
#define LC3_SUPPORTED_OCTETS_PER_FRAME 0x04
#define LC3_SUPPORTED_FRAMES_PER_SDU  0x05

/* Sampling frequency bit masks (used in type 0x01) */
#define LC3_FREQ_8KHZ    (1 << 0)
#define LC3_FREQ_11KHZ   (1 << 1)
#define LC3_FREQ_16KHZ   (1 << 2)
#define LC3_FREQ_22KHZ   (1 << 3)
#define LC3_FREQ_24KHZ   (1 << 4)
#define LC3_FREQ_32KHZ   (1 << 5)
#define LC3_FREQ_441KHZ  (1 << 6)   /* 44.1 kHz */
#define LC3_FREQ_48KHZ   (1 << 7)

BlueZ: Reading PACS with D-Bus

/* In BlueZ, you access PACS through the MediaEndpoint D-Bus interface.
 * When BlueZ discovers a PACS service, it creates a MediaEndpoint object
 * and calls your registered SelectConfiguration() D-Bus method.
 *
 * The flow in Python (bluetoothctl uses this internally):
 *
 * 1. Phone pairs with earbud
 * 2. BlueZ reads Sink PAC characteristic over GATT
 * 3. BlueZ calls your app's SelectConfiguration(capabilities) D-Bus method
 * 4. Your app picks the best codec config from capabilities
 * 5. Your app returns the chosen Codec_Specific_Configuration back to BlueZ
 * 6. BlueZ writes this config to the earbud's ASCS ASE characteristic
 */

/* Example D-Bus callback skeleton in C using GLib */
#include <gio/gio.h>

static void select_configuration(GDBusMethodInvocation *invocation,
                                 GVariant *capabilities)
{
    /* capabilities contains the PAC record data from the earbud */
    /* Parse it and pick the best supported config */

    GVariantBuilder builder;
    g_variant_builder_init(&builder, G_VARIANT_TYPE("ay"));

    /* Build Codec_Specific_Configuration for 48kHz, 10ms, 100 octets/frame */
    /* LTV format: Sampling Frequency */
    uint8_t config[] = {
        0x02, 0x01, 0x08,  /* Sampling Freq: 0x08 = 48kHz */
        0x02, 0x02, 0x02,  /* Frame Duration: 0x02 = 10ms  */
        0x05, 0x03, 0x01, 0x00, 0x00, 0x00, /* Audio Channel: Front Left */
        0x03, 0x04, 0x64, 0x00,  /* Octets per Codec Frame: 100 bytes */
        0x02, 0x05, 0x01         /* Codec Frames per SDU: 1             */
    };

    for (size_t i = 0; i < sizeof(config); i++)
        g_variant_builder_add(&builder, "y", config[i]);

    g_dbus_method_invocation_return_value(invocation,
        g_variant_new("(ay)", &builder));
}

LC3 (Low Complexity Communication Codec) is the mandatory codec for BLE Audio. Every BLE Audio device must support it. It was designed to achieve better audio quality than SBC at lower bitrates, while using less CPU than AAC or aptX.

LC3 Configuration Options — The Numbers You Set

Predefined Quality Settings — Mandatory Support Table

LC3 in Practice — Using liblc3 with ISO Sockets

/*
 * liblc3 is the open-source reference LC3 implementation.
 * Install: git clone https://github.com/google/liblc3
 *
 * This snippet shows the glue between LC3 encoder and ISO send()
 */

#include "lc3.h"   /* liblc3 header */

#define SAMPLE_RATE      48000
#define FRAME_US         10000   /* 10ms frame in microseconds */
#define OCTETS_PER_FRAME 100     /* 100 bytes/frame = 80Kbps */
#define NUM_CHANNELS     1

/* Calculate frame size in samples: 48000 * 10ms = 480 samples */
int frame_samples = lc3_frame_samples(FRAME_US, SAMPLE_RATE);

/* Set up LC3 encoder (allocated once, reused each frame) */
lc3_encoder_t encoder = lc3_setup_encoder(FRAME_US, SAMPLE_RATE,
                                           0,  /* 0 = no pitch detection */
                                           alloca(lc3_encoder_size(FRAME_US,
                                                                   SAMPLE_RATE)));

int16_t pcm_buf[480];    /* 10ms of raw PCM audio (480 samples at 48kHz) */
uint8_t lc3_buf[100];    /* Compressed LC3 output = one ISO SDU */

/* Main loop: encode and send every 10ms */
while (1) {
    /* Step 1: Get 10ms of PCM from audio capture (e.g. ALSA) */
    get_audio_capture(pcm_buf, frame_samples);

    /* Step 2: LC3-encode into 100 bytes */
    int ret = lc3_encode(encoder,
                         LC3_PCM_FORMAT_S16,  /* input format: signed 16-bit */
                         pcm_buf,             /* input PCM samples */
                         1,                   /* stride (channels) */
                         OCTETS_PER_FRAME,    /* output size: 100 bytes */
                         lc3_buf);            /* output buffer */
    if (ret != 0) {
        fprintf(stderr, "LC3 encode error: %d\n", ret);
        continue;
    }

    /* Step 3: Send one SDU over ISO socket */
    ssize_t sent = send(iso_sock_fd, lc3_buf, OCTETS_PER_FRAME, 0);
    if (sent != OCTETS_PER_FRAME) {
        perror("ISO send() incomplete");
    }

    /* ISO socket timestamps ensure we don't need usleep() manually —
     * the kernel blocks until the next ISO Interval if we send too fast */
}

/* On the RECEIVER side: */
uint8_t rx_buf[100];
int16_t pcm_out[480];

lc3_decoder_t decoder = lc3_setup_decoder(FRAME_US, SAMPLE_RATE,
                                           0,
                                           alloca(lc3_decoder_size(FRAME_US,
                                                                   SAMPLE_RATE)));
while (1) {
    ssize_t n = recv(iso_sock_fd, rx_buf, sizeof(rx_buf), 0);
    if (n <= 0) {
        /* Packet loss: pass NULL to decoder, it uses PLC (Packet Loss Concealment) */
        lc3_decode(decoder, NULL, 0, LC3_PCM_FORMAT_S16, pcm_out, 1);
    } else {
        lc3_decode(decoder, rx_buf, n, LC3_PCM_FORMAT_S16, pcm_out, 1);
    }
    /* Send pcm_out to ALSA playback... */
}

ASCS is the GATT service that controls the lifecycle of an audio stream. It lives on the earbud (Acceptor/Server side) and the phone (Initiator/Client) writes to it to move a stream from idle to active.

The core concept is an ASE (Audio Stream Endpoint). Think of an ASE as one audio pipe — it can be a Sink ASE (earbud receives audio) or a Source ASE (earbud sends mic audio). Each ASE has its own GATT characteristic and its own state machine.

ASE Control Point — Operations Written by the Phone

BlueZ BAP Plugin — How It Drives ASCS

/* BlueZ profiles/audio/bap.c handles the ASCS state machine automatically.
 * When your app calls the BlueZ MediaTransport.Acquire() D-Bus method,
 * BlueZ does the following GATT writes in sequence:
 *
 * 1. Write Config Codec (opcode 0x01) to ASE Control Point
 *    → Earbud sends Notification: ASE state = Codec Configured
 *
 * 2. Write Config QoS (opcode 0x02)
 *    → Earbud sends Notification: ASE state = QoS Configured
 *
 * 3. Write Enable (opcode 0x03) with context = Media
 *    → Earbud sends Notification: ASE state = Enabling
 *
 * 4. BlueZ calls LE_Set_CIG_Parameters + LE_Create_CIS (ISO socket connect())
 *    → HCI event: LE CIS Established
 *
 * 5. BlueZ writes Receiver Start Ready (opcode 0x04)
 *    → Earbud sends Notification: ASE state = Streaming
 *
 * 6. BlueZ returns the ISO file descriptor to your app via
 *    MediaTransport.Acquire() reply
 *
 * 7. Your app writes LC3 audio to that file descriptor (send())
 */

/* Simplified D-Bus sequence to start audio in Python */
import dbus

bus = dbus.SystemBus()

# Get the transport object (BlueZ discovered it via ASCS)
transport = bus.get_object("org.bluez", "/org/bluez/hci0/dev_AA_BB_CC_DD_EE_FF/fd0")
transport_iface = dbus.Interface(transport, "org.bluez.MediaTransport1")

# Acquire returns the ISO socket file descriptor + transport parameters
fd, mtu_r, mtu_w = transport_iface.Acquire()
# fd is the ISO socket — write LC3 audio to it every 10ms
print(f"Got ISO fd={fd}, read_mtu={mtu_r}, write_mtu={mtu_w}")

We learned in Part 1 that a BIS receiver must scan to find the broadcaster’s Periodic Advertising train, then read BIGInfo to sync to the BIG. This scanning takes time and wastes battery. PAST eliminates this scanning step.

PAST in the Context of the Auracast Use Case

Auracast is the official Bluetooth brand for public audio broadcasting (hearing loops, airport PA, gym TV audio). The BASS (Broadcast Audio Scan Service) profile provides a GATT-level way for the phone to act as a Broadcast Assistant: the user’s phone scans for broadcasts, the user picks one from the phone’s UI, and the phone uses PAST to tell the earbuds where to sync — no need for the earbuds to scan at all.

BASS GATT Characteristics

BlueZ: PAST HCI Command

/*
 * The HCI command that sends the sync info to the earbud is:
 * LE_Periodic_Advertising_Sync_Transfer (OGF=0x08, OCF=0x005A)
 *
 * Parameters:
 *   Connection_Handle: the ACL handle of the earbud connection
 *   Service_Data: opaque 16-bit value passed to earbud (can be BIS index)
 *   Sync_Handle: handle of the Periodic Advertising train we're synced to
 *
 * BlueZ does this via the MediaAssistant D-Bus interface.
 * The following is a simplified view of what BlueZ sends internally:
 */

struct hci_le_pa_sync_transfer {
    uint16_t connection_handle;  /* earbud's ACL connection handle */
    uint16_t service_data;       /* passed through to earbud */
    uint16_t sync_handle;        /* our PA sync handle (from LE_PA_Create_Sync) */
} __attribute__((packed));

/*
 * On the earbud side, the Controller generates:
 * HCI_LE_Periodic_Advertising_Sync_Transfer_Received event
 * which gives the earbud everything needed to sync to the BIG:
 *   - Sync_Handle (new local handle)
 *   - Advertiser address + SID
 *   - PA_Interval
 *   - Clock_Accuracy
 * The earbud then reads BIGInfo from the synced PA train.
 */

/* BlueZ exposes this through org.bluez.MediaAssistant1 D-Bus API */
/* When you call PushSource() on a broadcast receiver device, BlueZ
 * internally triggers the PAST HCI command */

Modern phones have one physical antenna shared between Wi-Fi (2.4GHz) and Bluetooth. They use a tiny hardware switch to alternate between them. The challenge: audio needs Bluetooth every 10ms, but Wi-Fi also needs the antenna for data. Who wins?

MWS — Modem and Wireless Stack Coexistence

For more complex coexistence (e.g. when both Wi-Fi and LTE also compete for the antenna), Bluetooth 5.0+ includes the MWS transport layer — a standardised way for the Bluetooth Controller to tell other radio subsystems “I need the antenna for the next 3ms”. The Controller asserts a hardware signal, and the Wi-Fi chip waits politely.

btmon is BlueZ’s HCI sniffer. It captures every HCI command and event between your Linux host and the Bluetooth Controller chip, and prints them in human-readable form. It is the most important tool for debugging BLE Audio setup problems.

Starting btmon

# Run in a separate terminal — it captures all HCI traffic live
sudo btmon

# Save to a file for later analysis
sudo btmon -w audio_session.btsnoop

# Open in Wireshark later
wireshark audio_session.btsnoop

What You See When a CIS is Created

/* Example btmon output when phone sets up CIS to earbud */

@ HCI Command: LE Set CIG Parameters (0x08|0x0062) plen 25
        CIG ID: 0x00
        C to P Interval: 10000 us     <-- 10ms ISO interval
        P to C Interval: 10000 us
        Worst Case SCA: 251-500 ppm
        Packing: Sequential (0x00)
        Framing: Unframed (0x00)
        CIS Count: 1
        CIS ID: 0x00
        Max SDU C to P: 100            <-- 100 bytes per frame
        Max SDU P to C: 0              <-- unidirectional (no mic)
        PHY C to P: LE 2M (0x02)
        PHY P to C: LE 2M (0x02)
        RTN C to P: 2                  <-- retransmission hint

@ HCI Event: Command Complete (0x0e) plen 12
        LE Set CIG Parameters (0x08|0x0062) ncmd 1
          Status: Success (0x00)
          CIG ID: 0x00
          CIS Count: 1
          Connection Handle: 0x0100    <-- CIS handle assigned

@ HCI Command: LE Create CIS (0x08|0x0064) plen 5
        CIS Count: 1
        CIS Handle: 0x0100
        ACL Handle: 0x0040            <-- existing ACL connection

@ HCI Event: LE CIS Established (0x13) subevent 0x19 plen 28
        Status: Success (0x00)
        CIS Handle: 0x0100
        C to P PHY: LE 2M (0x02)
        P to C PHY: LE 2M (0x02)
        NSE: 2                        <-- Controller chose NSE=2
        C to P Flush Timeout: 1       <-- FT=1
        P to C Flush Timeout: 1
        Max PDU C to P: 100
        Max PDU P to C: 0
        ISO Interval: 8               <-- 8 * 1.25ms = 10ms

Diagnosing Common Issues with btmon

Checking ISO Socket Timestamps in Code

/*
 * ISO sockets support SO_TIMESTAMPING to get the exact anchor point
 * of each packet — crucial for A/V sync with video playback.
 */

int enable = SOF_TIMESTAMPING_RX_HARDWARE |
             SOF_TIMESTAMPING_RAW_HARDWARE;
setsockopt(iso_fd, SOL_SOCKET, SO_TIMESTAMPING, &enable, sizeof(enable));

/* Then use recvmsg() to receive data + timestamp together */
struct msghdr msg;
struct iovec  iov;
uint8_t data_buf[100];
uint8_t ctrl_buf[CMSG_SPACE(sizeof(struct scm_timestamping))];

iov.iov_base = data_buf;
iov.iov_len  = sizeof(data_buf);

msg.msg_iov        = &iov;
msg.msg_iovlen     = 1;
msg.msg_control    = ctrl_buf;
msg.msg_controllen = sizeof(ctrl_buf);

ssize_t n = recvmsg(iso_fd, &msg, 0);

/* Extract hardware timestamp from ancillary data */
struct cmsghdr *cmsg;
for (cmsg = CMSG_FIRSTHDR(&msg); cmsg; cmsg = CMSG_NXTHDR(&msg, cmsg)) {
    if (cmsg->cmsg_type == SCM_TIMESTAMPING) {
        struct scm_timestamping *ts = (void *)CMSG_DATA(cmsg);
        /* ts->ts[2] = hardware timestamp = exact anchor point */
        printf("Anchor point: %ld.%09ld sec\n",
               ts->ts[2].tv_sec, ts->ts[2].tv_nsec);
    }
}

Let’s walk every single step from “earbuds power on” to “music playing” — mapping each step to the protocol, HCI command, and BlueZ API call involved.

These questions come up in BLE Audio / embedded Bluetooth engineering interviews.