Bluetooth® Low Energy audio - Stream Management

1. Introduction

The Bluetooth^® LE Audio Stream Management section regroups

• the Basic Audio Profile (BAP)
• the Audio Stream Control Service (ASCS)
• the Published Audio Capability Service (PACS)
• the Broadcast Audio Scan Service (BASS)

These profile and services are used to configure and establish unicast and broadcast audio streams.

Figure 1.1 Stream Management inside Generic Audio Framework

2. Basic Audio Profile (BAP)

The Basic Audio Profile defines roles and procedures to establish audio streams with remote devices. It's specified by the Bluetooth^® SIG and the full specification is accessible on their website.

2.1. Roles

The BAP introduces 6 roles:

• Unicast client: Establishes connection to the Unicast server, discovers its capabilities, and configures the audio stream. This role is used by a smartphone, a laptop, a television etc.
• Unicast server: Advertises its role, exposes its capabilities, accepts connection from the Unicast client to configure the audio stream. This role can be used by a headphone, a speaker, some hearing aids, some earbuds, or even a microphone.
• Broadcast source: Establishes a Broadcast Isochronous Stream and advertises all the information over extended advertising and periodic advertising.
• Broadcast sink: Scans advertising to find broadcast sources, and gets synchronized to receive audio streams.
• Scan delegator: Exposes its capabilities and waits for a broadcast assistant to receive some information of a broadcast source and commands. The scan delegator also requires the broadcast sink role to synchronize to the selected broadcast source.
• Broadcast assistant: Scans advertising to find broadcast sources, discovers the scan delegator capabilities. It sends the information of broadcast sources to the scan delegator.

2.2. Codec Configuration

To configure audio streams in Broadcast or Unicast mode, the BAP specifies the format of "Codec Specific Configuration". The Codec Specific Configuration is a byte array constituted of multiple Length-Type-Value (LTV) structures to define stream parameters like the Sampling Frequency or the Frame Duration.

Table 2.1 LTV Codec Configuration Structures

Parameter	Size	Description
LENGTH	1 Byte	Length of the type field + Length of the value field
TYPE	1 Byte	Type of the data: Sampling Frequency (0x01) Frame Duration (0x02) Audio Channel Allocation (0x03) Octets Per Codec Frame (0x04) Codec Frame Block Per SDU (0x05)
VALUE	LENGTH - 1 Byte	Value corresponding to the type See Assigned Numbers section 6.12.5

In Unicast mode, the codec specific configuration is used to configure an audio stream as Unicast Client and its value should be chosen according to the Published Audio Capabilities (see section 4) read on the remote Unicast Server.
In Broadcast mode, the codec specific config is used to configure a Broadcast Source audio stream and is exposed to remote Broadcast Sinks in the BASE structure (see section 2.4.1).

The following table summarize types found in Codec Configuration and common values:

Table 2.2 Common types and values of Codec Configuration

Type		Mandatory	Values
Sampling Frequency	0x01	Yes	0x01: 8 kHz 0x03: 16 kHz 0x05: 24 kHz 0x06: 32kHz 0x07: 44.1 kHz 0x08: 48kHz
Frame Duration	0x02	Yes	0x00: 7.5ms codec frames 0x01: 10ms codec frames
Octets Per Codec Frame	0x04	Yes	Number of bytes in a frame
Audio Channel Allocation	0x03	No (absence of value means one channel mono)	4-bytes bitfield of Audio Location values Bit 0: Front Left Bit 1: Front Right
Codec Frame Block Per SDU	0x05	No (default 1)	Number of Codec Frame per SDU

The following table is an example of a codec specific configuration:

Table 2.3 Example of codec configuration

Setting	Length	Type	Value
Sampling Frequency = 48KHz	0x02	0x01	0x08
Frame Duration = 10ms	0x02	0x02	0x01
Audio Channel Allocation = Front Left + Front Right (stereo)	0x05	0x03	0x03	0x00	0x00	0x00
Octets Per Codec Frame = 100 octets	0x03	0x04	0x64	0x00

2.3. Unicast Roles

The following diagram illustrates the interaction between the different unicast roles:

Figure 2.1 Interaction between a Unicast Client and a Unicast Server

2.3.1. Unicast Topologies

The BAP specifies 16 different topologies for the Unicast Roles. They define ways of establishing audio stream between one Central device and one or two Peripheral devices. The following table can be found in the BAP Specification and lists the possible topologies:

Table 2.4 Unicast audio configurations specified in BAP

Audio Configuration	Legend C------S	Num Servers	Sink ASEs	Source ASEs	Audio Channels per Sink ASE	Min Sink Audio Locations per Server	Audio Channels per Source ASE	Min Source Audio Locations per Server	CISes	Audio Streams
1	-------->	1	1		1				1	1
2	<--------	1		1			1		1	1
3	<------->	1	1	1	1		1		1	2
4	------->>	1	1		2	2			1	1
5	<----->>	1	1	1	2		1		1	2
6(i)	--------> -------->	1	2		1	2			2	2
6(ii)	--------> <--------	2	2		1	1			2	2
7(i)	--------> <--------	1	1	1	1		1		2	2
7(ii)	--------> <--------	2	1	1	1		1		2	2
8(i)	--------> <------->	1	2	1	1	2	1		2	3
8(ii)	--------> <------->	2	2	1	1	1	1	1	2	3
9(i)	<-------- <--------	1		2			1	2	2	2
9(ii)	<-------- <--------	2		2			1	1	2	2
10	<<-------	1		1			2	2	1	1
11(i)	<-------> <------->	1	2	2	1	2	1	2	2	4
11(ii)	<-------> <------->	2	2	2	1	1	1	1	2	4

The arrows in the "Legend" column illustrate the CISes (Connected Isochronous Streams) to establish between the devices. One arrow means 1 CIS. The arrow tip indicates the direction of the CIS (unidirectional or bidirectional). When the tip of the arrow is doubled, the CIS transport two channels. Topologies with "(i)" define interactions between 1 Central and 1 Peripheral, whereas topologies with "(ii)" define interactions between one Central and two Peripherals (earbud use-case for example).

For example:

• The configuration 4 defines a unidirectional stereo stream on one CIS to one device, which could be applied to transmit media to a headphone.
• The configuration 11(ii) defines two bidirectional CISes to two peripheral devices, which could be applied for a telephony use-case using earbuds where the two microphones on the earbuds would be used.

2.3.2. Unicast Codec Configurations

The BAP specifies LC3 codec configurations that can be used to establish audio streams between devices in Unicast mode. The following tables can be found in the BAP Specification and list the possible configurations:

Low Latency:

Table 2.5 Low Latency Unicast Codec Configuration specified in BAP

Set Name	Sampling Frequency (kHz)	Frame Duration (ms)	SDU Interval (µs)	Framing	Maximum SDU Size (Octets)	RTN	Max Transport Latency (ms)	Presentation Delay (µs)
8_1_1	8	7.5	7500	unframed	26 (27.734 kbps)	2	8	40000
8_2_1	8	10	10000	unframed	30 (24 kbps)	2	10	40000
16_1_1	16	7.5	7500	unframed	30 (32 kbps)	2	8	40000
16_2_1*	16	10	10000	unframed	40 (32 kbps)	2	10	40000
24_1_1	24	7.5	7500	unframed	45 (48 kbps)	2	8	40000
24_2_1	24	10	10000	unframed	60 (48 kbps)	2	10	40000
32_1_1	32	7.5	7500	unframed	60 (64 kbps)	2	8	40000
32_2_1	32	10	10000	unframed	80 (64 kbps)	2	10	40000
441_1_1	44.1	8.163	8163	framed	97 (95.06 kbps)	5	24	40000
441_2_1	44.1	10.884	10884	framed	130 (95.55 kbps)	5	31	40000
48_1_1	48	7.5	7500	unframed	75 (80 kbps)	5	15	40000
48_2_1	48	10	10000	unframed	100 (80 kbps)	5	20	40000
48_3_1	48	7.5	7500	unframed	90 (96 kbps)	5	15	40000
48_4_1	48	10	10000	unframed	120 (96 kbps)	5	20	40000
48_5_1	48	7.5	7500	unframed	117 (124.8 kbps)	5	15	40000
48_6_1	48	10	10000	unframed	155 (124 kbps)	5	20	40000

(*) Mandatory Configuration Unicast Client & Unicast Server

High reliability:

Table 2.6 High Reliability Unicast Codec Configuration specified in BAP

Set Name	Sampling Frequency (kHz)	Frame Duration (ms)	SDU Interval (µs)	Framing	Maximum SDU Size (Octets)	RTN	Max Transport Latency (ms)	Presentation Delay (µs)
8_1_2	8	7.5	7500	unframed	26 (27.734 kbps)	13	75	40000
8_2_2	8	10	10000	unframed	30 (24 kbps)	13	95	40000
16_1_2	16	7.5	7500	unframed	30 (32 kbps)	13	75	40000
16_2_2	16	10	10000	unframed	40 (32 kbps)	13	95	40000
24_1_2	24	7.5	7500	unframed	45 (48 kbps)	13	75	40000
24_2_2	24	10	10000	unframed	60 (48 kbps)	13	95	40000
32_1_2	32	7.5	7500	unframed	60 (64 kbps)	13	75	40000
32_2_2	32	10	10000	unframed	80 (64 kbps)	13	95	40000
441_1_2	44.1	8.163	8163	framed	97 (95.06 kbps)	13	80	40000
441_2_2	44.1	10.884	10884	framed	130 (95.55 kbps)	13	85	40000
48_1_2	48	7.5	7500	unframed	75 (80 kbps)	13	75	40000
48_2_2	48	10	10000	unframed	100 (80 kbps)	13	95	40000
48_3_2	48	7.5	7500	unframed	90 (96 kbps)	13	75	40000
48_4_2	48	10	10000	unframed	120 (96 kbps)	13	100	40000
48_5_2	48	7.5	7500	unframed	117 (124.8 kbps)	13	75	40000
48_6_2	48	10	10000	unframed	155 (124 kbps)	13	100	40000

The configurations are separated between two tables: Low Latency and High Reliability. High Reliability configurations use a higher Retransmission Number (RTN) and higher maximum transport latency to ensure that the audio packets are all correctly transmitted, but induce higher latency due to increased buffering of the audio packets. Most of the configurations use an "unframed" mode, meaning the spacing of the events on the air will be a multiple of the actual time between two audio Packets (SDU Interval).

2.4. Broadcast Roles

The following diagram illustrates the simple broadcast use-case, where a device acting as Broadcast Sink interacts with a Broadcast Source.

Figure 2.2 Broadcast Source and Broadcast Sink interaction

When the device acting as Broadcast Sink is not able to select which Broadcast Source to synchronize to, due to limited display or input capacity for example, the device may use the Scan Delegator role to ask a remote Broadcast Assistant to scan and select the Broadcast Source.

Figure 2.3 Broadcast Source, Broadcast Sink/Scan Delegator and Broadcast Assistant interaction

2.4.1. Broadcast Advertisement

A Broadcast Source advertises to be visible by remote Broadcast Sinks. It's advertisement is composed of two different types of advertising:

• Extended Advertising: Partially on advertising channels (37-38-39) and on connection channels, it permits to be visible when a Broadcast Sink is scanning
• Periodic Advertising: On connection channels, it contains large packets with information about the stream configuration

To synchronize to a Broadcast Source, a broadcast sink initiates a scanning procedure to find the extended advertising payload, which points to the Periodic Advertising payload, which itself points to the BIG (Broadcast Isochronous Group), which contains one or more BIS(es) (Broadcast Isochronous Stream) with audio stream(s). For more information about BIG/BIS, see the Introduction to Bluetooth® LE Audio wiki page.

Figure 2.4 Broadcast Source Advertising

2.4.1.1. BASE Structure

The Broadcast Audio Source Endpoint (BASE) structure is the data structure that permits to describe a Broadcast Source. It is located in the periodic advertising data and is constituted of 3 levels with the following items:

Table 2.7 BASE Structure content

Level	Parameter	Description
1 (Group)	Basic Audio Announcement Service UUID	UUID defined in Bluetooth Assigned Numbers: 0x1851
1 (Group)	Presentation Delay	Presentation Delay parameter. Refer to the the LC3 codec and audio data path wiki page, section Audio Latency
1 (Group)	Num Subgroups	Number of subgroups (level 2)
2 (Subgroup)	Num BIS	Number of BISes (level 3)
2 (Subgroup)	Codec ID	Codec ID for the subgroups. 0x0000000006 for the LC3 codec
2 (Subgroup)	Codec Specific Configuration	Series of LTV structures with common codec specific configuration for the subgroup
2 (Subgroup)	Metadata	Series of LTV Metadata structures
3 (BIS)	BIS Index	Unique index for the BIS
3 (BIS)	Codec Specific Configuration	Series of LTV structures with codec specific configuration for the bis

Example of a stereo Broadcast Source with one BIS:

Figure 2.5 BASE structure of a stereo Broadcast Source with one BIS

Example of a stereo Broadcast Source with two BISes:

Figure 2.6 BASE structure of a stereo Broadcast Source with two BIS

2.4.1.2. Broadcast Source Air Events

Over the air, a Broadcast Source emits four different types of packets:

• ADV_EXT_IND packets are sent on the three advertising channels (Extended Advertising)
• AUX_ADV_IND packets are sent on connection channels and contains the remaining data of ADV_EXT_IND packets (Extended Advertising)
• AUX_SYNC_IND packets are sent on connection channels (Periodic Advertising)
• BIS ISO Packets are sent on connection channels during BIG Events (BIG)

The following diagram illustrates a possible scheduling of those packets:

Figure 2.6 Air Events of a Broadcast Source

2.4.2. Broadcast Topologies

The BAP specifies three different topologies for the Broadcast Roles. They define ways of establishing audio stream between one Central device and one or two Peripheral devices. The following table can be found in the BAP Specification and lists the possible topologies:

Table 2.8 Broadcast Audio Configurations specified in BAP

Audio Configuration	Legend	Audio Channels per BIS	BISes	Audio Streams
12	---)))-->	1	1	1
13	---)))--> ---)))-->	1	2	2
14	---)))-->>	2	1	1

2.4.3. Broadcast Codec Configurations

The BAP specifies LC3 codec configurations that can be used to establish audio streams between devices in Broadcast mode. The following tables can be found in the BAP Specification and list the possible configurations: Low Latency:

Table 2.9 Low Latency Broadcast Codec Configurations specified in BAP

Set Name	Sampling Frequency (kHz)	Frame Duration (ms)	SDU Interval (µs)	Framing	Maximum SDU Size (Octets)	RTN	Max Transport Latency (ms)	Presentation Delay (µs)
8_1_1	8	7.5	7500	unframed	26 (27.734 kbps)	2	8	40000
8_2_1	8	10	10000	unframed	30 (24 kbps)	2	10	40000
16_1_1	16	7.5	7500	unframed	30 (32 kbps)	2	8	40000
16_2_1*	16	10	10000	unframed	40 (32 kbps)	2	10	40000
24_1_1	24	7.5	7500	unframed	45 (48 kbps)	2	8	40000
24_2_1**	24	10	10000	unframed	60 (48 kbps)	2	10	40000
32_1_1	32	7.5	7500	unframed	60 (64 kbps)	2	8	40000
32_2_1	32	10	10000	unframed	80 (64 kbps)	2	10	40000
441_1_1	44.1	8.163	8163	framed	97 (95.06 kbps)	4	24	40000
441_2_1	44.1	10.884	10884	framed	130 (95.55 kbps)	4	31	40000
48_1_1	48	7.5	7500	unframed	75 (80 kbps)	4	15	40000
48_2_1	48	10	10000	unframed	100 (80 kbps)	4	20	40000
48_3_1	48	7.5	7500	unframed	90 (96 kbps)	4	15	40000
48_4_1	48	10	10000	unframed	120 (96 kbps)	4	20	40000
48_5_1	48	7.5	7500	unframed	117 (124.8 kbps)	4	15	40000
48_6_1	48	10	10000	unframed	155 (124 kbps)	4	20	40000

(*) Mandatory Configuration Broadcast Source & Broadcast Sink
(**) Mandatory Configuration Broadcast Sink

High reliability:

Table 2.10 High Reliability Broadcast Codec Configurations specified in BAP

Set Name	Sampling Frequency (kHz)	Frame Duration (ms)	SDU Interval (µs)	Framing	Maximum SDU Size (Octets)	RTN	Max Transport Latency (ms)	Presentation Delay (µs)
8_1_2	8	7.5	7500	unframed	26 (27.734 kbps)	4	45	40000
8_2_2	8	10	10000	unframed	30 (24 kbps)	4	60	40000
16_1_2	16	7.5	7500	unframed	30 (32 kbps)	4	45	40000
16_2_2	16	10	10000	unframed	40 (32 kbps)	4	60	40000
24_1_2	24	7.5	7500	unframed	45 (48 kbps)	4	45	40000
24_2_2	24	10	10000	unframed	60 (48 kbps)	4	60	40000
32_1_2	32	7.5	7500	unframed	60 (64 kbps)	4	45	40000
32_2_2	32	10	10000	unframed	80 (64 kbps)	4	60	40000
441_1_2	44.1	8.163	8163	framed	97 (95.06 kbps)	4	54	40000
441_2_2	44.1	10.884	10884	framed	130 (95.55 kbps)	4	60	40000
48_1_2	48	7.5	7500	unframed	75 (80 kbps)	4	50	40000
48_2_2	48	10	10000	unframed	100 (80 kbps)	4	65	40000
48_3_2	48	7.5	7500	unframed	90 (96 kbps)	4	50	40000
48_4_2	48	10	10000	unframed	120 (96 kbps)	4	65	40000
48_5_2	48	7.5	7500	unframed	117 (124.8 kbps)	4	50	40000
48_6_2	48	10	10000	unframed	155 (124 kbps)	4	65	40000

Like the Unicast codec configurations, the Broadcast codec configurations are separated between a Low Latency table and a High Reliability table.

3. Audio Stream Control Service (ASCS)

The ASCS is hosted on a Unicast Server to permit remote Unicast Client to configure and establish audio streams between the two devices. It contains the current unicast state of the Unicast Server and its state machine. It's specified by the Bluetooth^® SIG and the full specification is accessible on their website.

3.1. Audio Stream Endpoints (ASE)

Audio Stream Endpoints (ASE) are hosted on Unicast Server and are controlled by remote Unicast Client to establish audio streams. They can be Sink or Source: a Sink ASE will host an audio stream directed from the Unicast Client to the Unicast Server and a Source ASE from the Unicast Server to the Unicast Client. An ASE can host multiple channels, concatenated on one CIS.

The following diagram illustrate a Unicast Server hosting three ASE: two Sink ASE and one Source ASE. The bidirectional CIS is established using ASE with ids 1 and 3, the unidirectional CIS uses the ASE with ID 2. The resulting configuration is configuration 8(i).

Figure 3.1 Example of unicast Server with 3 ASEs

3.2. ASE State Machine

The Source ASE State Machine is the following, as specified in the Bluetooth SIG ASCS Specification:

Figure 3.2 ASE Source State Machine

The Sink ASE State Machine is the following, as specified in the Bluetooth SIG ASCS Specification:

Figure 3.3 ASE Sink State Machine

For more details about ASE states and state machine, refer to the ASCS Specification section 3.

4. Published Audio Capability Service (PACS)

The PACS permits a Unicast Server or Broadcast Sink to expose its audio capabilities to remote Unicast Clients and Broadcast Assistants. It's specified by the Bluetooth^® SIG and the full specification is accessible on their website.

The PACS contains information about six items

• Sink Published Audio Capabilities
• Sink Audio Locations
• Source Published Audio Capabilities
• Source Audio Locations
• Available Audio Contexts
• Supported Audio Contexts

4.1. Published Audio Capability (PAC)

A PACS Server exposes one or multiple Published Audio Capability (PAC) records. These records indicate to a remote PACS Client which audio configurations are supported by the server.

Table 4.1 PAC Content

Parameter	Size (octets)	Value
Codec_ID	5	Codec ID, 0x0000000006 for the LC3 Codec
Codec_Specific_Capabilities_Length	1	Length, in octets, of the Codec_Specific_Capabilities value
Codec_Specific_Capabilities	Varies	Sequence of LTVs (Length-Type-Value) of Codec Capabilities See Assigned Numbers
Metadata_Length	1	Length of the Metadata field
Metadata	Varies	Sequence of LTVs (Length-Type-Value) of Metadata See Assigned Numbers

4.2. Audio Locations

A PACS Server exposes a bitfield of Audio Locations values supported. The possible values can be found in the Assigned Numbers specification. Possible common values for an Audio Location are:

• 0x00: Mono Audio without audio location. A mono speaker which is not part a speaker system can use this value.
• 0x01: Front Left
• 0x02: Front Right
• 0x03: Front Left + Front Right

4.3. Available/Supported Audio Contexts

A PACS Server exposes a bitfield of Context Type values currently available and a bitfield of Context Type values supported. The possible values can be found in the Assigned Numbers specification. Possible common values for a Context Type are:

• 0x0001: Unspecified
• 0x0002: Conversational
• 0x0004: Media
• 0x0008: Game

5. Broadcast Audio Scan Service (BASS)

The Broadcast Audio Scan Service is hosted on a Scan Delegator collocated with a Broadcast Sink to communicate with a remote Broadcast Assistant and exchange information and commands about available Broadcast Sources. It's specified by the Bluetooth^® SIG and the full specification is accessible on their website.

6. STM32Cube Firmware APIs

This section details how to do Bluetooth LE Audio Stream Management, using STM32CubeWBA Firmware.

6.1. Audio stream transition procedures

The procedures associated to the audio stream transition are specified in the section 7.3.1 of the Common Audio Profile

6.1.1. Unicast audio procedures

The unicast audio procedures (Unicast Audio Start, Unicast Audio Stop, Unicast Audio Update) described in the CAP specification are performed by the CAP Initiator thanks to the functions listed in the Table 6.1.

Table 6.1 Functions for unicast audio procedure management

Functions	Description	Header File
CAP_Unicast_AudioStart()	Start Unicast audio with specified CAP Acceptors according to sink/ source stream configuration.	cap.h
CAP_Unicast_AudioStop()	Stop Unicast Audio with specified CAP Acceptors.	cap.h
CAP_Unicast_AudioUpdate()	Change context type values and/or CCID values associated with one or more unicast audio streams.	cap.h

The section 3.5 (Table of the Basic audio profile describes the requirements of the CAP Acceptor in unicast server role concerning the audio capabilities configuration (see Table 3.5 of the specification), and the audio channels configuration (see section 3.5.3) to support according to the audio role (sink and/or source) and the audio locations.
Note that each Bluetooth® Low Energy audio use case profile specifies its audio capabilities and audio channels requirements.

During the unicast audio stream transition procedure, the CAP Initiator and the CAP Acceptor receive CAP events described inTable 6.3.

Table 6.3 CAP events of unicast audio transition

CAP procedure	Events	Description	CAP Initiator	CAP Acceptor
Audio start	CAP_UNICAST_AUDIO_STARTED.	Unicast audio start procedure is complete with all the specified CAP Acceptors.	X
Audio start	CAP_UNICAST_PREFERRED_QOS_REQ_EVT	Preferred QoS settings are requested for the specified audio stream endpoint.		X
Audio start	CAP_UNICAST_AUDIO_DATA_PATH_SETUP_REQ_EVT	Audio data path setup is requested for the specified audio stream endpoint. The CAP_Unicast_SetupAudioDataPath() shall be called to respond to the audio data path setup request.	X	X
Audio start	CAP_AUDIO_CLOCK_REQ_EVT	Audio clock subsystem should be updated to support submitted audio sample frequency	X	X
Audio start Audio stop	CAP_UNICAST_SERVER_ASE_STATE_EVT	The state of an audio stream endpoint has changed in unicast server side (CAP Acceptor) The state and the transition are described in the section 3 of the Audio stream control service '.		X
Audio start Audio stop	CAP_UNICAST_CLIENT_ASE_STATE_EVT	The state of an audio stream endpoint has changed in unicast client side (CAP Initiator) The state and the transition are described in the section 3 of the Audio stream control service '.	X
Audio start	CAP_UNICAST_AUDIO_CONNECTION_UP_EVT	Audio path is up for specified audio stream endpoint	X	X
Audio start Audio stop	CAP_UNICAST_AUDIO_CONNECTION_DOWN_EVT	Audio path is down for specified audio stream endpoint	X	X
Audio stop	CAP_UNICAST_AUDIO_STOPPED	Unicast audio stop procedure is complete with all the specified CAP Acceptors	X
Audio update	CAP_UNICAST_AUDIO_UPDATED	Unicast audio update procedure is complete with all the specified CAP Acceptors	X
Audio update	CAP_UNICAST_ASE_METADATA_UPDATED_EVT	Metadata associated to an audio stream endpoint is updated but audio stream endpoint State does not change	X	X

The Figure 6.1 shows the Functions/Events exchanged between the Generic Audio Framework (GAF) and the Application Layer during the CAP Unicast audio start procedure in CAP Initiator and CAP Acceptor side. In this example, the CAP Initiator starts a bidirectional unicast audio with one CAP Acceptor. Consequently, a source ASE and a Sink ASE are used by the CAP Initiator to set up the unicast audio.

Figure 6.1 Unicast audio start procedure sequence

In case of a failure occurs during the unicast audio start procedure, the CAP Initiator automatically aborts the procedure to move the audio stream endpoints in IDLE or CODEC CONFIGURED state. Once the abort operation is complete, the upper layer is notified with CAP_UNICAST_AUDIO_STARTED event including a failure status.

The Figure 6.2 shows the Functions/Events exchanged between the Generic Audio Framework (GAF) and the Application Layer during the CAP Unicast audio stop procedure in CAP Initiator and CAP Acceptor side. In this example, at the starting point, a source ASE and a Sink ASE are in streaming state when the CAP Initiator calls the CAP_Unicast_AudioStop() function.

Figure 6.2 Unicast audio stop procedure sequence

6.1.2. Broadcast audio procedures

6.1.2.1. CAP Initiator

The Figure 6.3 shows the broadcast state machine of the CAP Initiator in broadcast source role. The oval shapes represent the states of the CAP Initiator state machine. The labeled arrows represent the CAP broadcast function, which can cause a transition of the state machine.

Figure 6.3 CAP Initiator broadcast state machine

The broadcast audio procedures (Broadcast Audio Start, Broadcast Audio Stop, Broadcast Audio Update) described in the CAP specification are performed by the CAP Initiator thanks to the functions listed in the Table 6.3.

Table 6.3 CAP functions of broadcast audio transition management in the CAP Initiator side

Functions	Description	Header File
CAP_Broadcast_AudioStart()	Configure and start a broadcast source with the given parameters.	cap.h
CAP_Broadcast_AudioStop()	Stop a broadcast source and go to configured or idle State.	cap.h
CAP_Broadcast_AudioUpdate()	Update a streaming broadcast source metadata Cannot change an audio configuration.	cap.h

During the CAP broadcast audio procedures, the CAP Initiator is notified, over CAP events, that the procedure is complete and the state of the audio path associated to the audio stream has changed. These events notified during the CAP broadcast audio procedures are listed in theTable 6.4.

Table 6.4 CAP events of broadcast audio transition in CAP Initiator side

Events	Description	Header File
CAP_BROADCAST_AUDIOSTARTED_EVT	Event notified when the broadcast audio start procedure is complete.	cap_types.h
CAP_BROADCAST_AUDIOSTOPPED_EVT	Event notified when the broadcast audio stop procedure is complete.	cap_types.h
CAP_BROADCAST_AUDIO_UP_EVT	Event notified when the audio path has been set up.	cap_types.h
CAP_BROADCAST_AUDIO_DOWN_EVT	Event notified when the audio path has been removed.	cap_types.h

6.1.2.2. CAP Acceptor

When a broadcast audio stream is in progress, a CAP Acceptor, supporting broadcast sink role, which would be synchronized with the broadcast audio stream needs to call successive Bluetooth® Low Energy legacy functions and CAP functions to be able to be synchronized with the broadcast isochronous stream emitted by a CAP Initiator. The CAP functions allowing the CAP Acceptor to manage broadcast audio stream are listed in the Table 6.5.

Table 6.5 CAP functions of broadcast audio transition management in CAP Acceptor side

Functions	Description	Header File
CAP_Broadcast_StartAdvReportParsing()	Start parsing extended advertising events to look for broadcast UUIDs and generate CAP_ACC_BROADCAST_SOURCE_ADV_REPORT_EVT events An observation procedure must be started by the user in parallel.	cap.h
CAP_Broadcast_StopAdvReportParsing()	Stop parsing extended advertising events.	cap.h
CAP_Broadcast_StartPASync()	Start synchronization to a periodic advertising train.	cap.h
CAP_Broadcast_StartBIGSync()	Start synchronization to a broadcast isochronous group.	cap.h
CAP_Broadcast_StopPASync()	Stop synchronization to a periodic advertising train.	cap.h
CAP_Broadcast_StopBIGSync()	Stop synchronization to a broadcast isochronous group.	cap.h
CAP_Broadcast_ParseBASEGroup()	Parse a BASE payload reported by a CAP_ACC_BROADCAST_REPORT_EVT and fill a BAP_BASE_Group_t structure.	cap.h
CAP_Broadcast_ParseBASESubgroup()	Parse a BASE payload reported by a CAP_ACC_BROADCAST_REPORT_EVT and fill a BAP_BASE_Subgroup_t structure.	cap.h
CAP_Broadcast_ParseBASEBIS()	Parse a BASE payload reported by a CAP_BROADCAST_BASE_REPORT_EVT and fill a BAP_BASE_BIS_t structure.	cap.h

During the broadcast audio procedure in CAP Acceptor side, various CAP events are notified in the application layer resulting to operations started by the CAP Acceptor itself or the remote CAP Initiator. These CAP events received in the CAP Acceptor side are listed in the Table 6.6.

Table 6.6 CAP events of broadcast audio transition in CAP Acceptor side

Events	Description	Header File
CAP_BROADCAST_SOURCE_ADV_REPORT_EVT	Notified when a broadcast source has been scanned.	cap_types.h
CAP_BROADCAST_PA_SYNC_ESTABLISHED_EVT	Notified when synchronization to a periodic advertising train has been established.	cap_types.h
CAP_BROADCAST_BASE_REPORT_EVT	Notified when a BASE report is received.	cap_types.h
CAP_BROADCAST_BIGINFO_REPORT_EVT	Notified when a BIG info is received.	cap_types.h
CAP_BROADCAST_BIG_SYNC_ESTABLISHED_EVT	Notified when synchronization to a BIG has been established.	cap_types.h
CAP_BROADCAST_PA_SYNC_LOST_EVT	Notified when synchronization to a periodic advertising train has been lost.	cap_types.h
CAP_BROADCAST_BIG_SYNC_LOST_EVT	Notified when synchronization to a BIG has been lost.	cap_types.h
CAP_BROADCAST_AUDIO_UP_EVT	Notified when audio data path has been set up.	cap_types.h
CAP_BROADCAST_AUDIO_DOWN_EVT	Notified when audio data path has been removed.	cap_types.h

The Figure 6.4 describes the broadcast sink sequence diagram between the application, the Generic Audio Framework (GAF), the BLE Host Stack and the remote CAP Initiator during the broadcast audio stream synchronization procedure in CAP Acceptor side. To synchronize with broadcast audio stream, successive CAP broadcast operations are required in the CAP Acceptor side.

Figure 6.4 CAP Acceptor broadcast sequence diagram

6.2. Published Audio Capabilities APIs

For CAP Acceptor supporting Unicast server or Broadcast Sink role, the Generic Audio Framework provides functions to :

• Register sink/source audio channels accessible by the remote CAP Initiator or CAP Commander
• Set/Update the audio contexts (Conversational, media… Audio_Context_t defined in audio_types.h)
• Set/Update the audio locations (Front left, front right… Audio_Location_t defined in audio_types.h)
• Register/Update the audio capabilities of the unicast server

The Table 6.7 describes the functions dedicated to the CAP Acceptor in the unicast server role.

Table 6.7 CAP functions dedicated to CAP Acceptor for unicast audio configuration

Functions	Description	Header File
CAP_RegisterAudioChannels()	Register sink/source audio channels (and associated audio stream endpoint) supported by unicast server.	cap.h
CAP_SetSupportedAudioContexts()	Set/Update supported audio contexts for reception and transmission.	cap.h
CAP_SetAvailableAudioContexts()	Set available audio contexts for reception and transmission which will be used for BAP Announcement and for future connections.	cap.h
CAP_UpdateAvailableAudioContexts()	Update available audio contexts for reception and transmission associated to the specified remote CAP device.	cap.h
CAP_SetSnkAudioLocations()	Set/Update the supported sink audio locations.	cap.h
CAP_SetSrcAudioLocations()	Set/Update the supported source audio locations.	cap.h
CAP_RegisterSnkPACRecord()	Register published audio capabilities record for audio sink role.	cap.h
CAP_RegisterSrcPACRecord()	Register published audio capabilities record for audio source role.	cap.h
CAP_UpdatePACRecord()	Update a registered audio codec capabilities record for audio sink/source role.	cap.h