Basic Audio Profile

The Bluetooth SIG has established the following conventions for use of the words shall, must, will, should, may, can, is, and note in the development of specifications:

For clarity of the definition of those terms, see Core Specification Volume 1, Part E, Section 1.

Where a field in a packet, Protocol Data Unit (PDU), or other data structure is described as “Reserved for Future Use” (irrespective of whether in uppercase or lowercase), the device creating the structure shall set its value to zero unless otherwise specified. Any device receiving or interpreting the structure shall ignore that field; in particular, it shall not reject the structure because of the value of the field.

Where a field, parameter, or other variable object can take a range of values, and some values are described as “Reserved for Future Use,” a device sending the object shall not set the object to those values. A device receiving an object with such a value should reject it, and any data structure containing it, as being erroneous; however, this does not apply in a context where the object is described as being ignored or it is specified to ignore unrecognized values.

When a field value is a bit field, unassigned bits can be marked as Reserved for Future Use and shall be set to 0. Implementations that receive a message that contains a Reserved for Future Use bit that is set to 1 shall process the message as if that bit was set to 0, except where specified otherwise.

The acronym RFU is equivalent to Reserved for Future Use.

When a field value is an enumeration, unassigned values can be marked as “Prohibited.” These values shall never be used by an implementation, and any message received that includes a Prohibited value shall be ignored and shall not be processed and shall not be responded to.

Where a field, parameter, or other variable object can take a range of values, and some values are described as “Prohibited,” devices shall not set the object to any of those Prohibited values. A device receiving an object with such a value should reject it, and any data structure containing it, as being erroneous.

“Prohibited” is never abbreviated.

Binary numbers are written with a “0b” prefix, so 0b1101 is the same as the decimal number 13.

Hexadecimal numbers are written with a “0x” prefix, so 0x42 is the same as the decimal number 66. The letters “a” to “f” are used to represent the digits 10 to 15, so 0x1A is the same as the decimal number 26. The use of capital letters or lowercase letters in a hexadecimal number is not significant.

Underscore characters placed between the digits of binary or hexadecimal numbers are intended to make the numbers easier to interpret; these underscores do not affect the value. For example, 0b0010_1011 and 0b00101011 both equal the decimal number 43.

Any number not written in one of the above ways is a decimal.

Arrayed parameters are specified by using the following notation: ParameterA[i].

If more than one set of arrayed parameters is specified (e.g., ParameterA[i], ParameterB[i]), then, unless noted otherwise, the order of the parameters shall be: ParameterA[0], ParameterB[0], ParameterA[1], ParameterB[1], ParameterA[2], ParameterB[2], …ParameterA[n], ParameterB[n].

Two BAP roles are used for unicast audio: Unicast Server and Unicast Client.

Four BAP roles are used for broadcast audio: Broadcast Source, Broadcast Sink, Broadcast Assistant, and Scan Delegator.

The Unicast Server shall support a minimum ATT_MTU of 64 octets for one Unenhanced ATT bearer, or for at least one Enhanced ATT bearer if the Unicast Server supports Enhanced ATT bearers.

This section defines additional requirements for the Unicast Server beyond those defined in PACS [5].

Table 3.5 shows the Mandatory and Optional audio capability support requirements defined by this profile for the Unicast Server.

If the Unicast Server supports the Audio Sink role, the Unicast Server shall support reception and decoding of audio data that is encoded using the settings defined as Mandatory in Table 3.5. The Unicast Server may support reception and decoding of audio data that is encoded using the settings defined as Optional in Table 3.5 or any other settings defined by an implementation or by a higher-layer specification.

If the Unicast Server supports the Audio Sink role, the Unicast Server shall expose all supported audio capability settings for the Audio Sink role in one or more Sink PAC characteristics containing one or more PAC records.

If the Unicast Server supports the Audio Source role, the Unicast Server shall support encoding and transmission of audio data using the settings defined as Mandatory in Table 3.5. The Unicast Server may support encoding and transmission of audio data using the settings defined as Optional in Table 3.5 or any other settings defined by an implementation or a higher-layer specification.

If the Unicast Server supports the Audio Source role, the Unicast Server shall expose all supported audio capability settings for the Audio Source role in one or more Source PAC characteristics containing one or more PAC records.

If the Unicast Server supports vendor-specific codec audio capabilities, the Unicast Server shall use the format defined in Table 3.6 when populating the Codec_ID field in PAC records exposing vendor-specific audio capabilities.

This section defines additional requirements for the Unicast Server beyond those requirements defined in ASCS [4].

If the Unicast Server supports the Audio Sink role:

If the Unicast Server supports the Audio Source role:

To inform unconnected Unicast Clients that the Unicast Server is connectable and available to receive or transmit audio data for specific Context Type values (see Section 5.4), the Unicast Server shall transmit connectable extended advertising PDUs that contain the Service Data AD data type (see [3]), including additional service data defined in Table 3.7.

A Targeted Announcement (Announcement Type = 0x01) means the Unicast Server is connectable and is requesting a connection.

A General Announcement (Announcement Type = 0x00) means the Unicast Server is connectable but is not requesting a connection.

The AD format shown in Table 3.7 is defined in Volume 3, Part C, Section 11 in [1].

The Unicast Client shall support a minimum ATT_MTU of 64 octets for one Unenhanced ATT bearer, or for at least one Enhanced ATT bearer if the Unicast Client supports Enhanced ATT bearers.

GATT sub-procedure support requirements on Unenhanced ATT bearers required by all GATT clients are defined in Volume 3, Part G, Section 4.2 in [1].

The Unicast Client shall support the additional GATT sub-procedure requirements defined in Table 3.8.

Requirements in this section represent a minimum set of requirements for a client. Other GATT sub-procedures may be used if supported by both the client and the server.

C.1: Mandatory to support at least one Primary Service Discovery procedure.

C.2: Mandatory to support at least one Characteristic Discovery procedure.

The Unicast Client shall support the service and characteristic discovery procedures defined in Table 3.9.

The Unicast Client characteristic support requirements are defined in Table 3.10.

C.1: Mandatory to support if the Unicast Client supports the Audio Source role, otherwise Excluded.

C.2: Mandatory to support if the Unicast Client supports the Audio Sink role, otherwise Excluded.

This section defines service discovery procedures for the Unicast Client role.

This section defines characteristic discovery procedures for the Unicast Client.

Table 3.11 shows the Mandatory and Optional audio capability configuration support settings defined by this profile for the Unicast Client.

If the Unicast Client supports the Audio Source role, the Unicast Client shall support encoding and transmission of audio data using the settings defined as Mandatory in Table 3.11. The Unicast Client may support encoding and transmission of audio data using the settings defined as Optional in Table 3.11 or any other settings defined by an implementation or by a higher-layer specification.

If the Unicast Client supports the Audio Sink role, the Unicast Client shall support reception and decoding of audio data encoded using the settings defined as Mandatory in Table 3.11. The Unicast Client may support reception and decoding of audio data encoded using the settings defined as Optional in Table 3.11 or any other settings defined by an implementation or by a higher-layer specification.

The Broadcast Source shall support encoding and transmission of audio data using the settings defined as Mandatory in Table 3.12. The Broadcast Source may support encoding and transmission of audio data using the settings defined as Optional in Table 3.12 or any other settings defined by an implementation or by a higher-layer specification.

The Broadcast Source may support encoding and transmission of audio data encoded using vendor-specific codec audio capability settings. If the Broadcast Source transmits audio data encoded using vendor-specific codec audio capability settings, the Broadcast Source shall use the format defined in Table 3.13 when populating the Codec_ID field.

There are two types of audio announcements that are used in this profile for broadcast audio: Broadcast Audio Announcements (defined in Section 3.7.2.1) and Basic Audio Announcements (defined in Section 3.7.2.2).

Broadcast Audio Announcements are used to inform scanning devices that a periodic advertising train (PA), transmitted by the device that transmits the Broadcast Audio Announcement, is associated with a BIG that transports one or more broadcast Audio Streams.

Basic Audio Announcements expose broadcast Audio Stream parameters.

3.7.2.2. Basic Audio Announcements

The Broadcast Source shall use the parameters defined in Table 3.15 when transmitting periodic advertising PDUs used to expose broadcast Audio Stream parameters.

The parameters in Table 3.15 that follow the Basic Audio Announcement Service UUID are defined as the Broadcast Audio Source Endpoint (BASE) structure.

The AD format shown in Table 3.15 is defined in Volume 3, Part C, Section 11 in [1].

There are three numerically hierarchal levels to the BASE structure and the parameters contained within:

• Level 1: Group level. The BIG is the group.

• Level 2: Subgroup level. A subgroup is a collection of one or more BISes present in the BIG.

• Level 3: BIS level.

The following rules shall be met when populating the BASE:

• Rule 1: There shall be at least one subgroup.

• Rule 2: There shall be at least one BIS per subgroup.

• Rule 3: Every BIS in the BIG, denoted by its BIS_index value, shall only be present in one subgroup.

• Rule 4: Codec_Specific_Configuration parameters shall be present at Level 2 and may be present at Level 3. If an identical Codec_Specific_Configuration parameter value is present at Level 2 and at Level 3, the Codec_Specific_Configuration parameter value at Level 3 shall be treated as the only instance of that Codec_Specific_Configuration parameter value present. Where a Codec_Specific_Configuration parameter value includes length-type-value (LTV) structures, an LTV structure shall be considered an identical parameter to another LTV structure with the same Type field value, and the Value field of the LTV structure at Level 3 shall be treated as the only instance of that Value field that is present.

• Rule 5: Metadata_Length and Metadata parameter values may be changed while a broadcast Audio Stream is in the Streaming state (see Section 6.2.1). Changes to any other parameter values shall not occur while a broadcast Audio Stream is in the Streaming state.

Level	Parameter		Size (Octets)	Description
	Length		1	Length of Type and Value fields for AD data type
	Type: «Service Data - 16-bit UUID»		1	Defined in Bluetooth Assigned Numbers [2]
	Value		Varies	2-octet Service UUID followed by additional service data
1		Basic Audio Announcement Service UUID	2	Defined in Bluetooth Assigned Numbers [2]
1		Presentation_Delay	3	See Section 7 for description. Range: 0x000000 – 0xFFFFFF Units: µs All other values: RFU
1		Num_Subgroups	1	Number of subgroups used to group BISes present in the BIG Shall be at least 1, as defined by Rule 1
2		Num_BIS[i]	1	Number of BISes in the [ith] subgroup Shall be at least 1, as defined by Rule 2
2		Codec_ID[i]	5	Codec information for the [ith] subgroup Octet 0: Coding_Format Coding_Format values are defined in Bluetooth Assigned Numbers [2]. Octet 1–2: Company ID Company identifier values are defined in Bluetooth Assigned Numbers [2]. Shall be 0x0000 if octet 0 ≠ 0xFF Octet 3–4: Vendor-specific codec_ID Shall be 0x0000 if octet 0 ≠ 0xFF
2		Codec_Specific_Configuration_Length[i]	1	Length of the Codec_Specific_Configuration for the [ith] subgroup
2		Codec_Specific_Configuration[i]	Varies	Codec-specific configuration parameters for the [ith] subgroup Shall exist only if the Codec_Specific_Configuration_Length[i] ≠ 0x00
2		Metadata_Length[i]	1	Length of the Metadata for the [ith] subgroup
2		Metadata[i]	Varies	Series of LTV structures containing Metadata for the [ith] subgroup Shall exist only if the Metadata_Length[i] ≠ 0x00
3		BIS_index[i[k]]	1	BIS_index value for the [kth] BIS in the [ith] subgroup
3		Codec_Specific_Configuration_Length[i[k]]	1	Length of the Codec_Specific_Configuration for the [kth] BIS in the [ith] subgroup
3		Codec_Specific_Configuration[i[k]]	Varies	Codec-specific configuration parameters for the [kth] BIS in the [ith] subgroup Shall exist only if the Codec_Specific_Configuration_Length[i[k]] ≠ 0x00

Table 16. Table 3.15: Format of BASE used in Basic Audio Announcements

A logical example of a BASE structure is shown in Figure 3.1. In the example in Figure 3.1, the Broadcast Source is a television that transmits a BIG with four BISes, with each BIS representing a different language and Audio Location. There are two subgroups, each with two BISes.

The boxes with a single-line border represent Level 1 parameters, the boxes with a double-line border represent Level 2 parameters, and the boxes with a triple-line border represent Level 3 parameters.

Subgroup[0] has two BISes: BIS_Index[0] (BIS_index 0x01) and BIS_Index[1] (BIS_index 0x02), representing Media, Spanish language, FL, and FR for Subgroup[0].

Subgroup[1] has two BISes: BIS_Index[0] (BIS_index 0x03) and BIS_Index[1] (BIS_index 0x04), representing Media, English language, FL, and FR for Subgroup[1].

The Codec_ID and the Codec_Specific_Configuration (Sampling_Frequency (Section 4.3.2), Frame_Duration (Section 4.3.2), Octets_Per_Codec_Frame (Section 4.3.2)) parameter values at Level 2 apply to the respective subgroups and their respective BISes for which they have been defined.

The Metadata (Streaming_Audio_Contexts [2], Language [2]) parameter values at Level 2 apply to the respective subgroups and their respective BISes for which they have been defined.

The Codec_Specific_Configuration (Audio_Channel_Allocation (Section 4.3.2)) parameter values at Level 3 apply to the specific BIS_index values for which they have been defined in addition to the Codec_Specific_Configuration parameter values defined at Level 2.

Figure 6. Figure 3.1: Example BASE logical structure

The table structure for the example BASE illustrated in Figure 3.1 is shown in Table 3.16.

Level	Parameter		Size (Octets)	Value
	Length		1	Length of Type and Value fields for AD data type: 0x5D = 93 octets
	Type: «Service Data - 16-bit UUID»		1	Defined in Bluetooth Assigned Numbers [2]
	Value		92	2-octet Service UUID followed by additional service data
		Basic Audio Announcement Service UUID	2	Defined in Bluetooth Assigned Numbers [2]
1		Presentation_Delay	3	40 ms
1		Num_Subgroups	1	0x02: 2 Subgroups
2		Num_BIS[0]	1	0x02: 2 BIS in Subgroup[0]
2		Codec_ID[0]	5	Octet 0: 0x06 = LC3 Coding_Format Octet 1–2: 0x0000 Octet 3–4: 0x0000
2		Codec_Specific_Configuration_Length[0]	1	Length of the Codec_Specific_Configuration for Subgroup[0]: 0x0A octets
2		Codec_Specific_Configuration[0]	10	3 LTV structures for Subgroup[0] defining: LTV 1: Sampling_Frequency: 48000 Hz LTV 2: Frame_Duration: 10 ms LTV 3: Octets_Per_Codec_Frame: 100 octets
2		Metadata_Length[0]	1	Length of Subgroup[0] Metadata: 0x09 octets
2		Metadata[0]	9	2 LTV structures for Subgroup[0], defining: LTV 1: Streaming_Audio_Contexts: Media LTV 2: Language: Spanish
3		BIS_index[0[0]]	1	0x01
3		Codec_Specific_Configuration_Length[0[0]]	1	Length of the Codec_Specific_Configuration for BIS_index 0x01: 0x06 octets
3		Codec_Specific_Configuration[0[0]]	6	1 LTV structure for BIS_Index 0x01, defining: LTV 1 = Audio_Channel_Allocation: FL
3		BIS_index[0[1]]	1	0x02
3		Codec_Specific_Configuration_Length[0[1]]	1	Length of the Codec_Specific_Configuration for BIS_index 0x02: 0x06 octets
3		Codec_Specific_Configuration[0[1]]	6	1 LTV structure for BIS_Index 0x02, defining: LTV 1 = Audio_Channel_Allocation: FR
2		Num_BIS[1]	1	0x02: 2 BIS in Subgroup[1]
2		Codec_ID[1]	5	Octet 0: 0x06 = LC3 Coding_Format Octet 1–2: 0x0000 Octet 3–4: 0x0000
2		Codec_Specific_Configuration_Length[1]	1	Length of the Codec_Specific_Configuration for Subgroup[1]: 0x0A octets
2		Codec_Specific_Configuration[1]	10	3 LTV structures for Subgroup[1] defining: LTV 1: Sampling_Frequency: 48000 Hz LTV 2: Frame_Duration: 10 ms LTV 3: Octets_Per_Codec_Frame: 100 octets
2		Metadata_Length[1]	1	Length of Subgroup[1] Metadata: 0x09 octets
2		Metadata[1]	9	2 LTV structures for Subgroup[1] defining: LTV 1: Streaming_Audio_Contexts: Media LTV 2: Language: English
3		BIS_index[1[0]]	1	0x03
3		Codec_Specific_Configuration_Length[1[0]]	1	Length of the Codec_Specific_Configuration for BIS_index 0x03: 0x06 octets
3		Codec_Specific_Configuration[1[0]]	6	1 LTV structure for BIS_Index 0x03, defining: LTV 1 = Audio_Channel_Allocation: FL
3		BIS_index[1[1]]	1	0x04
3		Codec_Specific_Configuration_Length[1[1]]	1	Length of the Codec_Specific_Configuration for BIS_index 0x04: 6 octets
3		Codec_Specific_Configuration[1[1]]	6	1 LTV structure for BIS_Index 0x04, defining: LTV 1 = Audio_Channel_Allocation: FR

Table 17. Table 3.16: BASE structure for the logical BASE structure example shown in Figure 3.1

The Broadcast Sink shall support a minimum ATT_MTU of 64 octets for one Unenhanced ATT bearer or for at least one Enhanced ATT bearer if the Broadcast Sink supports Enhanced ATT bearers.

This section defines additional requirements for the Broadcast Sink beyond those defined in PACS [5].

The Broadcast Sink shall support reception and decoding of audio data that is encoded using the settings defined as Mandatory in Table 3.17. The Broadcast Sink may support reception and decoding of audio data that is encoded using settings defined as Optional in Table 3.17 or any other settings defined by an implementation or by a higher-layer specification.

The Broadcast Sink shall expose all supported audio capability settings in one or more Sink PAC characteristics containing one or more PAC records.

If the Broadcast Sink supports vendor-specific codec audio capabilities, the Broadcast Sink shall use the format defined in Table 3.18 when populating the Codec_ID field in PAC records, exposing vendor-specific audio capabilities.

The Scan Delegator shall support a minimum ATT_MTU of 64 octets for one Unenhanced ATT bearer or for at least one Enhanced ATT bearer if the Scan Delegator supports Enhanced ATT bearers.

This section defines additional requirements for the Scan Delegator beyond those requirements defined in BASS [6].

If the Scan Delegator implements a Broadcast Sink, then to inform unconnected Broadcast Assistants that the Broadcast Sink collocated with the Scan Delegator is connectable and available to receive audio data, the Scan Delegator shall transmit extended advertising PDUs that contain the Service Data AD data type (see [3]) and the Broadcast Audio Scan Service UUID as defined in Table 3.19.

The AD format shown in Table 3.19 is defined in Volume 3, Part C, Section 11 in [1].

The Broadcast Assistant shall support a minimum ATT_MTU of 64 octets for one Unenhanced ATT bearer or for at least one Enhanced ATT bearer if the Broadcast Assistant supports Enhanced ATT bearers.

GATT sub-procedure support requirements on Unenhanced ATT bearers required by all GATT clients are defined in Volume 3, Part G, Section 4.2 in [1].

The Broadcast Assistant shall support the additional GATT sub-procedure requirements defined in Table 3.20.

Requirements in this section represent a minimum set of requirements for a client. Other GATT sub-procedures may be used if supported by both the client and the server.

C.1: Mandatory to support at least one Primary Service Discovery procedure.

C.2: Mandatory to support at least one Characteristic Discovery procedure.

The Broadcast Assistant shall support the service and characteristic discovery procedures defined in Table 3.21.

Table 3.22 defines characteristic support requirements for the Broadcast Assistant role.

This section defines service discovery procedures for the Broadcast Assistant role.

This section defines characteristic discovery procedures for the Broadcast Assistant role.

Devices exposing support for the LC3 codec shall follow the requirements in this section when populating the Codec_Specific_Capabilities field in PAC records as defined in [5].

The Supported_Sampling_Frequencies LTV structure defined in Bluetooth Assigned Numbers [2] shall be present in the Codec_Specific_Capabilities field.

The Supported_Frame_Durations LTV structure defined in Bluetooth Assigned Numbers [2] shall be present in the Codec_Specific_Capabilities field.

The Supported_Audio_Channel_Counts LTV structure defined in Bluetooth Assigned Numbers [2] may be present in the Codec_Specific_Capabilities field. The absence of the Supported_Audio_Channel_Counts LTV structure shall be interpreted as equivalent to a Supported_Audio_Channel_Counts value of 0x01 (one Audio Channel supported).

The Supported_Octets_Per_Codec_Frame LTV structure defined in Bluetooth Assigned Numbers [2] shall be present in the Codec_Specific_Capabilities field.

The Supported_Max_Codec_Frames_Per_SDU LTV structure defined in Bluetooth Assigned Numbers [2] may be present in the Codec_Specific_Capabilities field. The absence of the Supported_Max_Codec_Frames_Per_SDU LTV structure shall be interpreted as equivalent to a Supported_Max_Codec_Frames_Per_SDU value of 1 codec frame per Audio Channel per SDU maximum.

Devices configuring an Audio Stream to use the LC3 codec shall follow the requirements in this section when initiating the Config Codec operation as defined in Section 5.6.1, or when configuring a broadcast Audio Stream, as defined in Section 6.3.

The Sampling_Frequency LTV structure defined in Bluetooth Assigned Numbers [2] shall be present in the Codec_Specific_Configuration field.

The Frame_Duration LTV structure defined in Bluetooth Assigned Numbers [2] shall be present in the Codec_Specific_Configuration field.

The Audio_Channel_Allocation LTV structure defined in Bluetooth Assigned Numbers [2] may be present in the Codec_Specific_Configuration field. The absence of the Audio_Channel_Allocation LTV structure shall be interpreted as a single channel with no specified Audio Location.

The Octets_Per_Codec_Frame LTV structure defined in Bluetooth Assigned Numbers [2] shall be present in the Codec_Specific_Configuration field. The Unicast Client and/or the Broadcast Source shall use a value for the Octets_Per_Codec_Frame LTV structure that lies within the Supported_Octets_Per_Codec_Frame value range exposed by the Unicast Server and/or exposed by the Broadcast Sink.

The Codec_Frame_Blocks_Per_SDU LTV structure defined in Bluetooth Assigned Numbers [2] may be present in the Codec_Specific_Configuration field. The absence of the Codec_Frame_Blocks_Per_SDU LTV structure shall be interpreted as equivalent to a Codec_Frame_Blocks_Per_SDU value of 0x01.

Devices exposing support for, or using, the LC3 codec may include any Metadata LTV structures defined in Bluetooth Assigned Numbers [2] in the Metadata field.

When exposing support for the LC3 codec in a PAC record, the Preferred_Audio_Context LTV structure defined in Bluetooth Assigned Numbers [2] may be present in the Metadata field. The absence of the Preferred_Audio_Contexts LTV structure in a PAC record means no preference for audio data Context Types are defined in that PAC record.

When using the LC3 codec with unicast or broadcast Audio Streams, the Streaming_Audio_Contexts LTV structure defined in Bluetooth Assigned Numbers [2] may be present in the Metadata field. The absence of the Streaming_Audio_Contexts LTV structure shall be considered equivalent to a Streaming_Audio_Contexts value that includes the bit defined as unspecified set to a value of 0b1 and all other bits set to a value of 0b0.

An example usage of the LC3 codec-specific parameters is shown in Figure 4.3.

The Codec_Specific_Capabilities parameter contains the Supported_Audio_Channel_Counts LTV structure.

Supported_Audio_Channel_Counts Value: 0x0B = 0b00001011: 1 channel supported, 2 channels supported, and 4 channels supported

The Codec_Specific_Configuration parameter contains the Audio_Channel_Allocation LTV structure.

Audio_Channel_Allocation Value: 0x000000003 = 0b00000000000000000000000000000011: Front left, Front right)

The Audio_Channel_Allocation value maps to a block of codec frames, and therefore to the LC3 Media Packet Payload field ordering as follows:

Figure 9. Figure 4.3: Example LC3 Codec_Specific_Capabilities and Codec_Specific_Configuration parameter usage

Single Audio Channel. One unidirectional CIS. Unicast Server is Audio Sink

Figure 4.4 shows an example of Audio Configuration 1. A Unicast Client in the Audio Source role transmits a single channel of audio data to a Unicast Server in the Audio Sink role using one unidirectional CIS.

Figure 10. Figure 4.4: Audio Configuration 1

The Audio Configuration 1 characteristics, Codec_Specific_Capabilities, and Codec_Specific_Configuration are shown in Table 4.3.

Single Audio Channel. One unidirectional CIS. Unicast Server is Audio Source.

Figure 4.5 shows an example of Audio Configuration 2. A Unicast Client in the Audio Sink role receives a single channel of audio data from a Unicast Server in the Audio Source role using one unidirectional CIS.

Figure 11. Figure 4.5: Audio Configuration 2

The Audio Configuration 2 characteristics, Codec_Specific_Capabilities, and Codec_Specific_Configuration are shown in Table 4.4.

Multiple Audio Channels. One bidirectional CIS. Unicast Server is Audio Sink and Audio Source.

Figure 4.6 shows an example of Audio Configuration 3. A Unicast Client in both the Audio Source and Audio Sink roles transmits a single channel of audio data to, and receives a single channel audio data from, a Unicast Server in the Audio Sink and Audio Source roles using one bidirectional CIS.

Figure 12. Figure 4.6: Audio Configuration 3

The Audio Configuration 3 characteristics, Codec_Specific_Capabilities, and Codec_Specific_Configuration are shown in Table 4.5.

Multiple Audio Channels. One unidirectional CIS. Unicast Server is Audio Sink.

Figure 4.7 shows an example of Audio Configuration 4. A Unicast Client in the Audio Source role transmits two channels of audio data to a Unicast Server in the Audio Sink role using one unidirectional CIS.

Figure 13. Figure 4.7: Audio Configuration 4

The Audio Configuration 4 characteristics, Codec_Specific_Capabilities, and Codec_Specific_Configuration are shown in Table 4.6.

Multiple Audio Channels. One bidirectional CIS. Unicast Server is Audio Sink and Audio Source.

Figure 4.8 shows an example of Audio Configuration 5. A Unicast Client in both the Audio Source and Audio Sink roles transmits two channels of audio data to, and receives a single channel of audio data from, a Unicast Server in the Audio Sink and Audio Source roles, using one bidirectional CIS.

Figure 14. Figure 4.8: Audio Configuration 5

The Audio Configuration 5 characteristics, Codec_Specific_Capabilities, and Codec_Specific_Configuration are shown in Table 4.7.

Multiple Audio Channels. Two unidirectional CISes. Unicast Server is Audio Sink.

Figure 4.9 shows an example of Audio Configuration 6(i). A Unicast Client in the Audio Source role transmits two channels of audio data to a Unicast Server in the Audio Sink role using two unidirectional CISes.

Figure 15. Figure 4.9: Audio Configuration 6(i)

The Audio Configuration 6(i) characteristics, Codec_Specific_Capabilities, and Codec_Specific_Configuration are shown in Table 4.8.

Multiple Audio Channels. Two unidirectional CISes. Two Unicast Servers. Unicast Server 1 is Audio Sink. Unicast Server 2 is Audio Sink.

Figure 4.10 shows an example of Audio Configuration 6(ii). A Unicast Client in the Audio Source role transmits two channels of audio data to a pair of Unicast Servers, both of which are in the Audio Sink role, using two unidirectional CISes.

Figure 16. Figure 4.10: Audio Configuration 6(ii)

The Audio Configuration 6(ii) characteristics, Codec_Specific_Capabilities, and Codec_Specific_Configuration for Unicast Server 1 are shown in Table 4.9.

The Audio Configuration 6(ii) characteristics, Codec_Specific_Capabilities and Codec_Specific_Configuration for Unicast Server 2 are shown in Table 4.10.

Multiple Audio Channels. Two unidirectional CISes. Unicast Server is Audio Sink and Audio Source.

Figure 4.11 shows an example of Audio Configuration 7(i). A Unicast Client in the Audio Source and Audio Sink roles transmits a single channel of audio data to, and receives a single channel of audio data from, a Unicast Server in the Audio Sink and Audio Source roles, using two unidirectional CISes.

Figure 17. Figure 4.11: Audio Configuration 7(i)

The Audio Configuration 7(i) characteristics, Codec_Specific_Capabilities, and Codec_Specific_Configuration are shown in Table 4.11.

Multiple Audio Channels. Two Unidirectional CISes. Two Unicast Servers. Unicast Server 1 is Audio Sink. Unicast Server 2 is Audio Source.

Figure 4.12 shows an example of Audio Configuration 7(ii). A Unicast Client in the Audio Source and Audio Sink roles transmits a single channel of audio data to a Unicast Server in the Audio Sink role and receives a single channel of audio data from a second Unicast Server in the Audio Source role, using two unidirectional CISes.

Figure 18. Figure 4.12: Audio Configuration 7(ii)

The Audio Configuration 7(ii) characteristics, Codec_Specific_Capabilities, and Codec_Specific_Configuration for Unicast Server 1 are shown in Table 4.12.

The Audio Configuration 7(ii) characteristics, Codec_Specific_Capabilities, and Codec_Specific_Configuration for Unicast Server 2 are shown in Table 4.13.

Multiple Audio Channels. One bidirectional CIS and one unidirectional CIS. Unicast Server is Audio Sink and Audio Source.

Figure 4.13 shows an example of Audio Configuration 8(i). A Unicast Client in the Audio Source and Audio Sink roles transmits two channels of audio data to, and receives a single channel of audio data from, a Unicast Server in the Audio Sink and Audio Source roles, using one unidirectional CIS and one bidirectional CIS.

Figure 19. Figure 4.13: Audio Configuration 8(i)

The Audio Configuration 8(i) characteristics, Codec_Specific_Capabilities, and Codec_Specific_Configuration are shown in Table 4.14.

Multiple Audio Channels. One bidirectional CIS and one unidirectional CIS. Two Unicast Servers. Unicast Server 1 is Audio Sink and Audio Source. Unicast Server 2 is Audio Sink.

Figure 4.14 shows an example of Audio Configuration 8(ii). A Unicast Client in the Audio Source and Audio Sink roles transmits a single channel of audio data to, and receives a single channel of audio data from, a Unicast Server in the Audio Sink and Audio Source roles, using one bidirectional CIS. The Unicast Client also transmits a second channel of audio data to a second Unicast Server in the Audio Sink role, using one unidirectional CIS.

Figure 20. Figure 4.14: Audio Configuration 8(ii)

The Audio Configuration 8(ii) characteristics, Codec_Specific_Capabilities, and Codec_Specific_Configuration for Unicast Server 1 are shown in Table 4.15.

The Audio Configuration 8(ii) characteristics, Codec_Specific_Capabilities, and Codec_Specific_Configuration for Unicast Server 2 are shown in Table 4.16.

Multiple Audio Channels. Two unidirectional CISes. Unicast Server is Audio Source.

Figure 4.15 shows an example of Audio Configuration 9(i). A Unicast Client in the Audio Sink role receives two channels of audio data from a Unicast Server in the Audio Source role, using two unidirectional CISes.

Figure 21. Figure 4.15: Audio Configuration 9(i)

The Audio Configuration 9(i) characteristics, Codec_Specific_Capabilities, and Codec_Specific_Configuration are shown in Table 4.17.

Multiple Audio Channels. Two unidirectional CISes. Two Unicast Servers. Unicast Server 1 is Audio Source. Unicast Server 2 is Audio Source.

Figure 4.16 shows an example of Audio Configuration 9(ii). A Unicast Client in the Audio Sink role receives two channels of audio data from two Unicast Servers, both in the Audio Source role, using two unidirectional CISes.

Figure 22. Figure 4.16: Audio Configuration 9(ii)

The Audio Configuration 9(ii) characteristics, Codec_Specific_Capabilities, and Codec_Specific_Configuration for Unicast Server 1 are shown in Table 4.18.

The Audio Configuration 9(ii) characteristics, Codec_Specific_Capabilities, and Codec_Specific_Configuration for Unicast Server 2 are shown in Table 4.19.

Multiple Audio Channels. One unidirectional CIS. Unicast Server is Audio Source.

Figure 4.17 shows an example of Audio Configuration 10. A Unicast Client in the Audio Sink role receives two channels of audio data from a Unicast Server in the Audio Source role, using one unidirectional CIS.

Figure 23. Figure 4.17: Audio Configuration 10

The Audio Configuration 10 characteristics, Codec_Specific_Capabilities, and Codec_Specific_Configuration are shown in Table 4.20.

Multiple Audio Channels. Two bidirectional CISes. Unicast Server is Audio Sink and Audio Source.

Figure 4.18 shows an example of Audio Configuration 11(i). A Unicast Client in the Audio Source and Audio Sink roles transmits two channels of audio data to, and receives two channels of audio data from, a Unicast Server in the Audio Sink and Audio Source roles, using two bidirectional CISes.

Figure 24. Figure 4.18: Audio Configuration 11(i)

The Audio Configuration 11(i) characteristics, Codec_Specific_Capabilities, and Codec_Specific_Configuration that enable Audio Configuration 11(i) are shown in Table 4.21.