Audio Stream Control

Audio Stream Control Service (ASCS)

ASCS (LC3 codec and Auracast." data-category="LE Audio">LE Audio stream configuration." data-category="LE Audio">Audio Stream Control Service) is a GATT service defined as part of the LE Audio specification. It runs on the audio peripheral (earbuds, hearing aids, speakers) and manages the lifecycle of audio stream endpoints that the Central device uses to set up CIS streams.

ASE State Machine

ASCS exposes one or more Audio Stream Endpoints (ASE), each modeled as a GATT Characteristic with a well-defined state machine. The states progress through the following sequence:

1. Idle -- ASE is not configured
2. Codec Configured -- Central has selected the LC3 codec and parameters
3. QoS Configured -- Transport parameters (interval, latency, retransmissions) are set
4. Enabling -- Controller is establishing the CIS connection
5. Streaming -- Audio data is flowing
6. Disabling / Releasing -- Teardown in progress

The Central writes to the ASE Control Point characteristic to drive transitions. Each transition triggers a Notification back to the Central with the updated ASE state and any status information.

Codec Configuration

During the Codec Configured state, the Central selects parameters including sampling frequency (8-48 kHz), frame duration (7.5 or 10 ms), audio channel allocation (mono, stereo), and target bitrate. The peripheral advertises its supported configurations via Published Audio Capabilities (PACS), another GATT Service that lists available codec capabilities, sink/source audio locations, and supported contexts (media, conversational, game).

Relationship to BAP and CAP

ASCS sits at the service layer within the BAP (Basic Audio Profile) stack. BAP defines the procedures that orchestrate ASCS operations, while CAP adds coordinated set handling for multi-device scenarios (e.g., left/right earbud pair). When implementing an LE Audio peripheral, ASCS and PACS are the two mandatory ATT">GATT services on the device.

Implementation

Most BLE chip vendors provide ASCS as part of their LE Audio SDK libraries. On the nRF5340, the ASCS implementation runs on the application core while isochronous data flows through the network core. Developers typically interact with ASCS through high-level API callbacks rather than manipulating the state machine directly.