Before diving deep, here is a simple view of where ASCS sits in the overall LE Audio stack. Understanding this context will help you avoid confusion about what ASCS does vs what other layers handle.

Key Insight: PACS tells the client what audio codecs the device supports. ASCS is what the client uses to say “OK, I want to use LC3 at 16 kHz — set it up!” The actual audio then flows over a CIS, not over GATT.

These terms come up throughout the entire spec. Get these clear in your head before reading further.

ASCS exposes exactly three types of GATT characteristics. There can be multiple instances of Sink ASE and Source ASE characteristics, but only one instance of the ASE Control Point.

Important Rules: At least one of Sink ASE or Source ASE must be supported (you cannot have an ASCS with neither). There can be only one ASCS instance on a server. The service UUID must be set to «Audio Stream Control» as defined in Bluetooth Assigned Numbers.

Multi-Client Isolation

One clever design in ASCS is that the server exposes separate ASE characteristic values for each connected client. Even though there is only one GATT attribute handle for the Sink ASE characteristic, Client A and Client B each get their own independent copy of the value. Client A’s configuration does not affect Client B’s view of the ASE, and vice versa.

Example: An earbud that supports 3 concurrent unicast streams for a single client would expose 3 ASE characteristics — maybe two Sink ASEs (music + voice) and one Source ASE (microphone). Each characteristic can serve one stream per client.

Every ASE has its own state machine running on the server. When you understand the state machine, you understand ASCS. All the control operations are just ways to move between these states.

The 7 States

Sink ASE Flow (Happy Path)

For a Sink ASE (like a speaker in an earbud), the normal audio setup and teardown path looks like this:

Source ASE Difference — The Disabling State

A Source ASE (microphone) behaves slightly differently when disabled. Instead of jumping directly to QoS Configured, it goes through a Disabling intermediate state. This is because the audio source keeps transmitting until the receiver (phone) explicitly signals it is ready to stop receiving. This gives the receiver time to finish processing buffered audio.

Sink ASE Disable: Sink ASE skips the Disabling state entirely. Disable operation takes a Sink ASE directly from Enabling or Streaming to QoS Configured.

Link Loss Behavior

What happens if the BLE connection drops unexpectedly? ASCS has specific rules:

• CIS link loss while in Streaming or Disabling: Server immediately transitions that ASE to QoS Configured state.
• LE-ACL link loss (the BLE connection itself) in any state: Server immediately transitions all affected ASEs to Releasing state, then runs the Released operation.

All control operations are written to the ASE Control Point characteristic. Every write starts with a 1-byte opcode, followed by the operation parameters. The server responds with a notification on the same characteristic.

Purpose: Agree on which audio codec to use, and at what configuration (sample rate, frame duration, etc.). This is the very first step in setting up any audio stream. Once this succeeds, the server moves to Codec Configured state and also tells the client its preferred QoS parameters (like what PHY it wants).

Both the client and server can initiate Config Codec. A server might autonomously configure itself when it powers on.

Packet Format

Example: Configuring LC3 at 16 kHz on ASE #1

/*
 * Config Codec operation — write to ASE Control Point characteristic
 * Configuring ASE_ID=1 with LC3, 16kHz, balanced latency, LE 2M PHY
 *
 * Byte layout of the write:
 */

uint8_t config_codec_op[] = {
    0x01,       /* Opcode: Config Codec */
    0x01,       /* Number_of_ASEs: 1 */

    /* ASE[0] parameters */
    0x01,       /* ASE_ID: 1 */
    0x02,       /* Target_Latency: 0x02 = Balanced latency and reliability */
    0x02,       /* Target_PHY: 0x02 = LE 2M PHY */

    /* Codec_ID (5 bytes) */
    0x06,       /* Coding_Format: LC3 */
    0x00, 0x00, /* Company_ID: 0x0000 (standard codec) */
    0x00, 0x00, /* Vendor_Codec_ID: 0x0000 (standard codec) */

    /* Codec_Specific_Configuration (LTV format, defined by BAP) */
    0x10,       /* Codec_Specific_Config_Length: 16 bytes */

    /* LTV: Sampling_Frequency = 16000 Hz (0x03) */
    0x02,       /* Length */
    0x01,       /* Type: Sampling_Frequency */
    0x03,       /* Value: 0x03 = 16000 Hz */

    /* LTV: Frame_Duration = 10ms (0x01) */
    0x02,       /* Length */
    0x02,       /* Type: Frame_Duration */
    0x01,       /* Value: 0x01 = 10ms */

    /* LTV: Octets_per_Codec_Frame = 40 */
    0x03,       /* Length */
    0x04,       /* Type: Octets_per_Codec_Frame */
    0x28, 0x00  /* Value: 40 bytes (little-endian) */
};

/*
 * Write this buffer to the ASE Control Point characteristic
 * using GATT Write Characteristic Value or Write Without Response
 */
bt_gatt_write(conn, ase_ctrl_point_handle, config_codec_op, sizeof(config_codec_op));

/*
 * Server will respond with a notification on ASE Control Point:
 * [Opcode=0x01][Num_ASEs=1][ASE_ID=1][Response_Code=0x00][Reason=0x00]
 *
 * Then server sends notification on Sink ASE characteristic with:
 * [ASE_ID=1][ASE_State=0x01 (Codec Configured)][Framing][Preferred_PHY]...
 */

After Success: The server responds on the ASE characteristic with state = 0x01 (Codec Configured) and also fills in its preferred QoS parameters — Preferred_PHY, Preferred_Retransmission_Number, Max_Transport_Latency, Presentation_Delay_Min, Presentation_Delay_Max. These are hints for the next step (Config QoS).

Purpose: Set the Quality of Service parameters for the CIS that will carry this ASE’s audio. You are telling the server: “I will create a CIS with CIG_ID X and CIS_ID Y, with these exact timing and reliability parameters.” Only the client can initiate this operation.

The parameters you send here map directly to the HCI LE Set CIG Parameters command (HCI_LE_Set_CIG_Parameters). So the client’s host layer uses these values when it sets up the CIG/CIS at the controller level.

Packet Format

Example: Config QoS for LC3 16kHz

/*
 * Config QoS operation for ASE_ID=1
 * Setting up CIG_ID=0x01, CIS_ID=0x01 with 10ms frame interval
 */

uint8_t config_qos_op[] = {
    0x02,           /* Opcode: Config QoS */
    0x01,           /* Number_of_ASEs: 1 */

    0x01,           /* ASE_ID: 1 */
    0x01,           /* CIG_ID: 1 */
    0x01,           /* CIS_ID: 1 */

    /* SDU_Interval: 10000 us = 10ms (3 bytes, little-endian) */
    0x10, 0x27, 0x00,

    0x00,           /* Framing: 0x00 = Unframed */
    0x02,           /* PHY: LE 2M */

    /* Max_SDU: 40 bytes (2 bytes little-endian) */
    0x28, 0x00,

    0x02,           /* Retransmission_Number: 2 */

    /* Max_Transport_Latency: 10ms = 10 (2 bytes little-endian) */
    0x0A, 0x00,

    /* Presentation_Delay: 40000 us (3 bytes little-endian) */
    0x40, 0x9C, 0x00
};

bt_gatt_write(conn, ase_ctrl_point_handle, config_qos_op, sizeof(config_qos_op));

/*
 * On success, server notifies ASE characteristic with:
 * ASE_State = 0x02 (QoS Configured)
 * Additional params include: CIG_ID, CIS_ID, SDU_Interval, Framing,
 * PHY, Max_SDU, Retransmission_Number, Max_Transport_Latency, Presentation_Delay
 */

Rule to remember: Two Sink ASEs for the same client cannot share the same CIG_ID + CIS_ID combination. Similarly for Source ASEs. If you try this, the server rejects with Response_Code 0x09, Reason 0x0A (Invalid_ASE_CIS_Mapping).

Purpose: Tell the server to enable the ASE and apply any Metadata. This moves the ASE to Enabling state. The CIS can now be established (though the ASE is not yet coupled to it). Only the client initiates Enable.

Metadata in this context means audio context type information — things like “this audio is voice” or “this audio is media” or “this audio is for notifications.” This helps devices make decisions about routing, processing, and priority.

Packet Format

/*
 * Enable operation — ASE_ID=1, with Media audio context metadata
 *
 * Streaming_Audio_Contexts LTV:
 *   Type 0x02 = Streaming_Audio_Contexts
 *   Value: bitmask — 0x0004 = Media
 */

uint8_t enable_op[] = {
    0x03,           /* Opcode: Enable */
    0x01,           /* Number_of_ASEs: 1 */

    0x01,           /* ASE_ID: 1 */
    0x04,           /* Metadata_Length: 4 bytes of metadata follow */

    /* LTV: Streaming_Audio_Contexts = Media */
    0x03,           /* Length: 3 bytes of LTV content */
    0x02,           /* Type: Streaming_Audio_Contexts */
    0x04, 0x00      /* Value: 0x0004 = Media (little-endian) */
};

bt_gatt_write(conn, ase_ctrl_point_handle, enable_op, sizeof(enable_op));

/*
 * Server moves ASE to Enabling state (0x03)
 *
 * Special case for Sink ASE:
 * If a CIS is already established AND server is acting as Audio Sink
 * AND server is ready to receive audio, the server MAY autonomously
 * call Receiver Start Ready and skip directly to Streaming state
 * without sending a notification for the Enabling state first.
 */

Purpose: This operation is the “green light” signal that says the Audio Sink is ready to start receiving audio. It completes the coupling of the ASE to the CIS and moves the ASE to Streaming state.

Who sends it depends on which side is the Audio Sink:

• If the server is the Sink (earbud receiving music): The server sends Receiver Start Ready autonomously.
• If the client is the Sink (phone receiving voice from earbud): The client writes Receiver Start Ready to the ASE Control Point.

Direction Rule: If the client tries to send Receiver Start Ready for a Sink ASE (where the server is already the sink), the server rejects it with Response_Code 0x05 (Invalid ASE direction). This operation is only valid for Source ASEs when initiated by the client.

Packet Format

/*
 * Receiver Start Ready — client signals it is ready to receive
 * audio from the Source ASE (Source ASE = server sending voice audio)
 * This is the client acting as Audio Sink for a Source ASE.
 */

uint8_t recv_start_ready[] = {
    0x04,   /* Opcode: Receiver Start Ready */
    0x01,   /* Number_of_ASEs: 1 */
    0x02    /* ASE_ID: 2 (the Source ASE, e.g. microphone) */
};

bt_gatt_write(conn, ase_ctrl_point_handle, recv_start_ready, sizeof(recv_start_ready));

/*
 * Server transitions Source ASE to Streaming state (0x04)
 * Audio data now flows over the CIS
 */

Purpose: Stop the audio stream for an ASE. Behavior differs between Sink and Source ASEs.

• Sink ASE: Disable moves directly to QoS Configured. No Disabling intermediate state.
• Source ASE: Disable moves to Disabling state first. The source keeps transmitting until Receiver Stop Ready is sent.

Packet Format

/* Disable Sink ASE #1 — goes directly to QoS Configured */
uint8_t disable_sink[] = { 0x05, 0x01, 0x01 };
bt_gatt_write(conn, ase_ctrl_point_handle, disable_sink, sizeof(disable_sink));
/* ASE #1 moves: Streaming → QoS Configured */

/* Disable Source ASE #2 — goes to Disabling first */
uint8_t disable_source[] = { 0x05, 0x01, 0x02 };
bt_gatt_write(conn, ase_ctrl_point_handle, disable_source, sizeof(disable_source));
/* ASE #2 moves: Streaming → Disabling */
/* Source ASE stays in Disabling and keeps transmitting */
/* Client must follow with Receiver Stop Ready (0x06) to complete teardown */

Purpose: The second part of stopping a Source ASE. After Disable puts a Source ASE into Disabling state, the Audio Sink sends Receiver Stop Ready to confirm it has finished consuming audio. This moves the Source ASE back to QoS Configured state.

Only valid for Source ASEs. Only the client (acting as Audio Sink) sends this. The server rejects it with error 0x05 (Invalid ASE direction) if called for a Sink ASE.

/* Receiver Stop Ready for Source ASE #2 */
uint8_t recv_stop_ready[] = { 0x06, 0x01, 0x02 };
bt_gatt_write(conn, ase_ctrl_point_handle, recv_stop_ready, sizeof(recv_stop_ready));
/* Source ASE #2 moves: Disabling → QoS Configured */

Purpose: Change the Metadata for an active ASE without tearing down and re-establishing the stream. Valid in Enabling and Streaming states. Both client and server can initiate this.

Use case: A call comes in while music is playing. The phone changes the Streaming_Audio_Contexts metadata from “Media” to “Conversational” — without stopping the audio stream and restarting it from scratch.

/*
 * Update Metadata — change audio context from Media to Conversational
 * while ASE is in Streaming state
 */

uint8_t update_metadata_op[] = {
    0x07,           /* Opcode: Update Metadata */
    0x01,           /* Number_of_ASEs: 1 */
    0x01,           /* ASE_ID: 1 */
    0x04,           /* Metadata_Length: 4 bytes */

    /* LTV: Streaming_Audio_Contexts = Conversational (0x0002) */
    0x03,           /* Length */
    0x02,           /* Type: Streaming_Audio_Contexts */
    0x02, 0x00      /* Value: 0x0002 = Conversational */
};

bt_gatt_write(conn, ase_ctrl_point_handle, update_metadata_op, sizeof(update_metadata_op));
/* ASE stays in Streaming state, only metadata changes */

Purpose: Completely tear down all resources associated with an ASE. Immediately decouples the ASE from its CIS, tears down the CIS, and frees all configuration. This is the “nuclear option” — it takes you all the way back to Idle or Codec Configured (if server caches the codec config).

Valid from any state that has a configuration — Codec Configured, QoS Configured, Enabling, Streaming, Disabling. Can be initiated by either client or server.

/* Release ASE #1 — from any configured state */
uint8_t release_op[] = { 0x08, 0x01, 0x01 };
bt_gatt_write(conn, ase_ctrl_point_handle, release_op, sizeof(release_op));

/*
 * Server transitions ASE to Releasing state (0x06)
 * Server tears down the CIS
 * Server then autonomously runs Released operation:
 *   - If caching codec: ASE goes to Codec Configured (0x01)
 *   - If not caching: ASE goes to Idle (0x00)
 * Server sends notification on ASE characteristic with final state
 * Server does NOT send notification on ASE Control Point for Released
 */

Purpose: This is the final cleanup step after Release or after an LE-ACL link loss. The server runs this autonomously — the client does not write anything. The server decides whether to cache the codec configuration or start fresh from Idle.

No Control Point Notification: Unlike all other operations, the Released operation does NOT generate a notification on the ASE Control Point characteristic. The server only notifies the ASE characteristic itself with the new state.

Here is the full sequence showing how a phone (Client/Audio Source) sets up a music stream to earbuds (Server/Audio Sink). This is the most common LE Audio unicast scenario.

When you read a Sink ASE or Source ASE characteristic, this is the format you get back. The server also sends this same format in notifications whenever the ASE state changes.

Base Format (All States)

Additional_ASE_Parameters in Codec Configured State (0x01)

When ASE_State = 0x01, the Additional_ASE_Parameters include the server’s preferred QoS hints plus the codec configuration:

PD = Presentation Delay, CSC = Codec Specific Configuration, RTx = Retransmission

Reading ASE Characteristic in Code

/*
 * Callback when ASE characteristic notification is received
 * Parse the ASE value to extract state and parameters
 */
void on_ase_notification(const uint8_t *data, uint16_t len)
{
    if (len < 2) {
        /* Minimum is ASE_ID + ASE_State */
        return;
    }

    uint8_t ase_id    = data[0];
    uint8_t ase_state = data[1];

    printf("ASE_ID: %d, State: %d\n", ase_id, ase_state);

    switch (ase_state) {
    case 0x00: /* Idle */
        printf("ASE %d is Idle — no configuration\n", ase_id);
        break;

    case 0x01: /* Codec Configured */
        if (len >= 2 + 1 + 1 + 1 + 2 + 3 + 3 + 3 + 3 + 5 + 1) {
            uint8_t framing        = data[2];
            uint8_t pref_phy       = data[3];
            uint8_t pref_rtx       = data[4];
            uint16_t max_latency   = data[5] | (data[6] << 8);
            /* Presentation_Delay_Min at data[7..9] (3 bytes LE) */
            uint32_t pd_min = data[7] | (data[8] << 8) | (data[9] << 16);
            /* Presentation_Delay_Max at data[10..12] */
            uint32_t pd_max = data[10] | (data[11] << 8) | (data[12] << 16);

            printf("  Framing: %s\n", framing ? "Framed" : "Unframed");
            printf("  Preferred PHY: 0x%02X\n", pref_phy);
            printf("  Preferred RTx Number: %d\n", pref_rtx);
            printf("  Max Transport Latency: %d ms\n", max_latency);
            printf("  Presentation Delay: %d us - %d us\n", pd_min, pd_max);
        }
        break;

    case 0x02: /* QoS Configured */
        printf("ASE %d — QoS configured, CIG_ID=%d CIS_ID=%d\n",
               ase_id, data[2], data[3]);
        break;

    case 0x03: /* Enabling */
        printf("ASE %d — Enabling, CIG_ID=%d CIS_ID=%d\n",
               ase_id, data[2], data[3]);
        break;

    case 0x04: /* Streaming */
        printf("ASE %d — STREAMING! Audio data flowing.\n", ase_id);
        break;

    case 0x05: /* Disabling */
        printf("ASE %d — Disabling (Source ASE decoupling)\n", ase_id);
        break;

    case 0x06: /* Releasing */
        printf("ASE %d — Releasing resources\n", ase_id);
        break;

    default:
        printf("ASE %d — Unknown state 0x%02X\n", ase_id, ase_state);
    }
}

When the server rejects or cannot complete an operation, it notifies the ASE Control Point with a Response_Code and a Reason. Understanding these helps you debug ASCS issues.

Reading the Control Point Notification Response

/*
 * ASE Control Point notification format when responding to a client operation:
 *
 * [Opcode: 1B] [Number_of_ASEs: 1B] [ASE_ID: 1B] [Response_Code: 1B] [Reason: 1B]
 * ... repeated for each ASE in the original request ...
 *
 * Special case for 0x01 (Unsupported Opcode) and 0x02 (Invalid Length):
 * Number_of_ASEs = 0xFF, ASE_ID = 0x00, Reason = 0x00
 */

void on_cp_notification(const uint8_t *data, uint16_t len)
{
    if (len < 2) return;

    uint8_t opcode       = data[0];
    uint8_t num_ases     = data[1];

    /* Check for whole-operation errors first */
    if (num_ases == 0xFF) {
        uint8_t resp_code = data[3]; /* 0x01 or 0x02 */
        printf("Operation 0x%02X rejected: %s\n", opcode,
               resp_code == 0x01 ? "Unsupported Opcode" : "Invalid Length");
        return;
    }

    /* Per-ASE responses */
    uint16_t offset = 2;
    for (int i = 0; i < num_ases; i++) {
        if (offset + 3 > len) break;
        uint8_t ase_id    = data[offset];
        uint8_t resp_code = data[offset + 1];
        uint8_t reason    = data[offset + 2];

        if (resp_code == 0x00) {
            printf("ASE %d: Operation 0x%02X SUCCESS\n", ase_id, opcode);
        } else {
            printf("ASE %d: FAILED — Response_Code=0x%02X Reason=0x%02X\n",
                   ase_id, resp_code, reason);
        }
        offset += 3;
    }
}

This section is important if you are implementing ASCS on a server that can handle multiple connected clients at once.

• Each client gets its own ASE namespace: ASE_ID values are per-client. Client A’s ASE_ID=1 and Client B’s ASE_ID=1 are completely separate ASEs even if they share the same GATT attribute handle.
• Separate characteristic values per client: When a client reads the Sink ASE characteristic, it sees only the value associated with itself. It cannot see another client’s state.
• ASE_ID stability: If the server has a bonded (trusted) relationship with a client, the ASE_ID for that client must not change across reconnections. This allows the client to remember which ASE is which.
• ASE_ID must not be 0x00: The value 0x00 is reserved and the server must never assign it as an ASE_ID.
• Server controls resource allocation: If Client A is using all the server’s ASEs in Streaming state, the server can refuse to enable ASEs for Client B. Or it can decide to release Client A’s ASEs to accommodate Client B. This is implementation-defined.

These GATT sub-procedures are mandatory on any ASCS server:

Encryption is Required: All three ASCS characteristics require an encrypted BLE connection. You must pair/bond before you can interact with ASCS. This is why ASCS works only on encrypted links.

If you are working with BlueZ on Linux, ASCS is handled by the bluetooth/audio/ subsystem. Here are the key points to know.

BlueZ DBus Interface for ASCS

In BlueZ, ASCS is exposed through the org.bluez.MediaEndpoint1 DBus interface. When you use A2DP LE Audio, BlueZ internally handles ASCS negotiations. However, for direct GATT-level access you interact with the GATT characteristics directly.

#!/bin/bash
# Using bluetoothctl to explore ASCS on a connected LE Audio device

# Connect to the device (must be BLE LE Audio capable)
bluetoothctl connect AA:BB:CC:DD:EE:FF

# List all GATT attributes - look for ASCS UUID: 0x184E
bluetoothctl -- list-attributes AA:BB:CC:DD:EE:FF

# Read the Sink ASE characteristic
# (replace the UUID/path with the actual one from list-attributes)
bluetoothctl -- select-attribute /org/bluez/hci0/dev_AA_BB_CC_DD_EE_FF/service001a/char001b
bluetoothctl -- read

# Example output: [0x01, 0x00]
# ASE_ID=1, ASE_State=0x00 (Idle)

# Subscribe to notifications on Sink ASE
bluetoothctl -- notify on

Python Script to Interact with ASCS (using bluepy/dbus)

#!/usr/bin/env python3
"""
ASCS exploration script using BlueZ DBus interface
Reads ASE characteristics and subscribes to state change notifications
"""

import dbus
import dbus.mainloop.glib
from gi.repository import GLib

# ASCS Service UUID
ASCS_UUID         = "0000184e-0000-1000-8000-00805f9b34fb"
SINK_ASE_UUID     = "00002bc4-0000-1000-8000-00805f9b34fb"
SOURCE_ASE_UUID   = "00002bc5-0000-1000-8000-00805f9b34fb"
ASE_CP_UUID       = "00002bc6-0000-1000-8000-00805f9b34fb"

# State names for human-readable output
ASE_STATES = {
    0x00: "Idle",
    0x01: "Codec Configured",
    0x02: "QoS Configured",
    0x03: "Enabling",
    0x04: "Streaming",
    0x05: "Disabling",
    0x06: "Releasing"
}

def parse_ase_value(data):
    """Parse ASE characteristic value and print human-readable info"""
    if len(data) < 2:
        print("  [ERROR] ASE value too short")
        return

    ase_id    = data[0]
    ase_state = data[1]
    state_name = ASE_STATES.get(ase_state, f"Unknown (0x{ase_state:02X})")

    print(f"  ASE_ID: {ase_id}")
    print(f"  ASE_State: {ase_state:#04x} = {state_name}")

    if ase_state == 0x01:  # Codec Configured
        if len(data) >= 4:
            framing   = data[2]
            pref_phy  = data[3]
            print(f"  Framing: {'Unframed supported' if framing == 0 else 'Framed only'}")
            print(f"  Preferred PHY: {pref_phy:#04x}")

    elif ase_state == 0x02:  # QoS Configured
        if len(data) >= 4:
            cig_id = data[2]
            cis_id = data[3]
            print(f"  CIG_ID: {cig_id}, CIS_ID: {cis_id}")

    elif ase_state in (0x03, 0x04, 0x05):  # Enabling/Streaming/Disabling
        if len(data) >= 4:
            cig_id = data[2]
            cis_id = data[3]
            print(f"  CIG_ID: {cig_id}, CIS_ID: {cis_id}")
            if len(data) > 4:
                meta_len = data[4]
                print(f"  Metadata Length: {meta_len}")


def build_config_codec_op(ase_id):
    """
    Build Config Codec operation bytes for LC3 at 16kHz, 10ms frames
    Opcode=0x01, single ASE, LC3 codec, balanced latency, LE 2M PHY
    """
    return bytes([
        0x01,       # Opcode: Config Codec
        0x01,       # Number_of_ASEs: 1
        ase_id,     # ASE_ID
        0x02,       # Target_Latency: Balanced
        0x02,       # Target_PHY: LE 2M
        # Codec_ID (5 bytes): LC3 standard
        0x06, 0x00, 0x00, 0x00, 0x00,
        # Codec_Specific_Config (LTV format)
        0x10,       # Config length: 16 bytes
        # LTV: Sampling_Frequency = 16000 Hz
        0x02, 0x01, 0x03,
        # LTV: Frame_Duration = 10ms
        0x02, 0x02, 0x01,
        # LTV: Octets_per_Codec_Frame = 40
        0x03, 0x04, 0x28, 0x00,
        # LTV: Codec_Frames_per_SDU = 1
        0x02, 0x05, 0x01,
    ])


# Main interaction flow
if __name__ == "__main__":
    print("ASCS Tutorial — Read ASE state and print info")
    print("In a real application, you would:")
    print("1. Connect to the BLE device (must be bonded/encrypted)")
    print("2. Discover ASCS service (UUID 0x184E)")
    print("3. Find Sink ASE, Source ASE, ASE Control Point characteristics")
    print("4. Subscribe to notifications on all three")
    print("5. Write Config Codec to ASE Control Point to start setup")
    print("6. Follow the state machine flow shown in this tutorial")

Common Implementation Mistakes