![]() |
Coming soon |
1. STM32WBA BLE Audio Firmware Architecture
The Bluetooth® LE Audio Firmware, as represented by the Bluetooth® Special Interest Group (Bluetooth® SIG), is composed to two layers :
- Profiles grouped in a block called Generic Audio Framework (BAP, MCP,CCP...). This layer is responsible to offer to the Audio Use Case Profiles all the features required to implement an audio application.
- Profiles dedicated to specific Audio Use Case (PBP : Published Broadcast Profile, HAP : Hearing Aids Profile...). This part is closed to the final audio application and interact with the Generic Audio Framework.
The single Core Arm® Cortex®-M33 STM32WBA Bluetooth® low energy solution is designed to develop audio application firmware based on Audio Use Case Profiles on top of the Generic Audio Framework.
The Generic Audio Framework is on top of the Bluetooth® Low Energy Firmware Stack (Controller & Host) and offers Audio Stream Management service access and Remote Control service access.
1.1. Bluetooth® LE Audio Firmware Package Overview
STMicroelectronics provides, in the STM32CubeWBA MCU Package, a software solution to develop audio application.
The figure below represents the Firmware Architecture of the Bluetooth® LE Audio provided in the STM32CubeWBA MCU Package.
STM32WBA Bluetooth® Bluetooth® LE Audio Firmware Architecture |
---|
The Audio Use Case Profiles implementation is available in Source Code format in each Audio Project assigned to an audio application based on a specific Audio Use Case as defined by the Bluetooth® SIG.
The Generic Audio Framework is included in an entity named "BLE Audio Stack" which includes :
- The entire Generic Audio Framework
- Audio Utils (Audio Timer Service, RAM allocation Utils)
- Audio Management in charge to handle internal tasks and Bluetooth® LE events received from the LE Host Stack.
The "BLE Audio Stack is delivered in library format :
- The library is available in the \Middlewares\ST\STM32_WPAN\ble\audio\lib directory.
- The header files declaring the types and the APIs are available in the \Middlewares\ST\STM32_WPAN\ble\audio\Inc directory
STM32WBA Bluetooth® Package Overview |
---|
1.2. Bluetooth® LE Audio Framework Interfaces
The Header files associated to the Bluetooth® LE Audio Stack are described in the table. There are located in the \Middlewares\ST\STM32_WPAN\ble\audio\Inc directory.
File Name | Description |
---|---|
audio_types.h | this file defines types for Bluetooth® LE Audio as specified by the Bluetooth SIG |
ble_audio_stack.h | this file defines Bluetooth® LE Audio Stack interfaces initialization, task processing. |
ble_audio_plat.h | this file defines types and declares APIs required for Audio Stack integration on platform : AES, RNG, Non-Volatile Memory, Timer, Traces |
cap_types.h | This file defines :
|
cap.h | This file declares functions to manage procedures defined by the Common Audio Profile. |
bap_bufsize.h | This file defines MACROs to calculate the number of GATT Services, GATT Attributes and ATT Array size allocation required to support a Basic Audio Profile configuration. |
bap_types.h | This file defines specific Basic Audio Profile types . |
ltv_utils.h | This file declares functions to parse information included in LTV structure. |
ccp_types.h | This file defines :
|
ccp.h | This file declares functions to manage Call Control operations. |
mcp_types.h | This file defines :
|
mcp.h | This file declares functions to manage Media Control operations. |
csip_types.h | This file defines :
|
csip.h | This file declares function to register Service Instance for CSIP Set Member role. |
micp_types.h | This file defines :
|
micp.h | This file declares function to manage Microphone Control operations not handle in CAP procedures. |
vcp_types.h | This file defines :
|
vcp.h | This file declares function to manage Volume Control operations not handle in CAP procedures. |
The figure below represents the Header Files of the Generic Audio Framework.
STM32WBA Bluetooth® Header Files of the Generic Audio Framework |
---|
2. Bluetooth® LE Audio Stack Integration
The base of the of the Bluetooth® LE Audio Stack is the BLE Host and the Link Layer.
In addition, the Bluetooth® LE Audio Stack requires external SW modules :
- Service Controller Module
- Linked List Manager Module
- Debug/Traces Module
- Timer Server Module
- Bare Metal Sequencer / Operation System Module
- Non-Volatile Memory Manager Module
- Advanced Encryption Standard (AES) Module
- Random Number Generator Module
STM32WBA Bluetooth® Bluetooth® LE Audio Stack Integration Dependencies |
---|
2.1. Host Stack
The Basic Audio Profile of the Generic Audio Framework, included in the Bluetooth® LE Audio Stack, is in charge to manage features based on :
- Extended Advertising features
- ISO features
- Periodic Advertising features
- Periodic Advertising Sync Transfer features
These features accesses are provided by the BLE Host Stack.
Moreover, all the profiles, and their associated services, in the Generic Audio Framework are based on ATT service model. Consequently, each profile requires an access of GATT operations. These GATT operation accesses are provided by the BLE Host Stack.
2.2. Service Controller
The Service Controller, located in the Middlewares\ST\STM32_WPAN\ble\svc folder, is a Software Block used by the Bluetooth® LE Audio Stack to register handlers through which asynchronous HCI, GAP and GATT events would be notified from the BLE Host to the profiles of the Generic Audio Framework.
In the Bluetooth® LE Audio Stack, a centric audio manager block is responsible to submit the events to the profiles of the Generic Audio Framework. For this reason, the Bluetooth® LE Audio Stack integration requires for the Service Controller configuration:
- BLE_CFG_SVC_MAX_NBR_CB shall be incremented by 1
- BLE_CFG_MAX_NBR_CB shall be incremented by 1
Bluetooth® LE Audio Stack Integration Dependency - Service Controller Module |
---|
2.3. Linked List Manager
The Linked List Manager offers functions and types used by the Bluetooth® LE Audio Stack to handle its internal linked lists.
The List Manager functions are implemented in a file named stm_list.c included in each project folder.
The List Manager types and APIs are declared in stm_list.h also present in each project folder.
Bluetooth® LE Audio Stack Integration Dependency - Linked List Manager Module |
---|
2.4. Debug/Traces
The Debug Traces IP is useful for the Bluetooth® LE Audio Stack in case of debug reports are enabled in the library. For this, the Bluetooth® LE Audio Stack requests the system to print some Debug Traces thanks to the BLE_AUDIO_PLAT_DbgLog() API. This API shall be implemented in project.
Bluetooth® LE Audio Stack Integration Dependency - Debug/Traces Module |
---|
The BLE Audio Trace BLE_AUDIO_PLAT_DbgLog() API is declared in ble_audio_plat.h header file in the Middlewares\ST\STM32_WPAN\ble\audio\Inc folder.
Functions | Header File |
---|---|
void BLE_AUDIO_PLAT_DbgLog(char *format,...)
|
ble_audio_plat.h |
2.5. Timer Server
The Bluetooth® LE Audio Stack requires a One-Shot Reference timer on which are multiplexed all the internal BLE Audio SW timers.
The Bluetooth® LE Audio Stack calls the BLE_AUDIO_PLAT_TimerStart() to create the reference timer and start it. When Bluetooth® LE Audio Stack needs to stop the timer, it calls the BLE_AUDIO_PLAT_TimerStop(). The Bluetooth® LE Audio Stack requires to get remaining time of the reference timer. For this, it calls the BLE_AUDIO_PLAT_TimerGetRemainMs().
The Reference Timer expiration should be notified, from the system layer, in a background task, thanks to the callback function passed in parameter of the BLE_AUDIO_PLAT_TimerStart() API.
These APIs shall be implemented in the project.
Bluetooth® LE Audio Stack Integration Dependency - Timer Server Module |
---|
The BLE Audio Timer APIs are declared in ble_audio_plat.h header file in the Middlewares\ST\STM32_WPAN\ble\audio\Inc folder.
Functions | Header File |
---|---|
void BLE_AUDIO_PLAT_TimerStart(void *pCallbackFunc,void *pParam,uint32_t Timeout)
|
ble_audio_plat.h |
void BLE_AUDIO_PLAT_TimerStop(void)
|
ble_audio_plat.h |
uint32_t BLE_AUDIO_PLAT_TimerGetRemainMs(void)
|
ble_audio_plat.h |
2.6. Bare Metal Sequencer / Operation System
The Bluetooth® LE Audio Stack requires registration of a dedicated Task responsible to run the internal BLE Audio Profiles process.
The dedicated Task should call the BLE_AUDIO_STACK_Task() function.
When the BLE Audio Task requests to be executed, the Bluetooth® LE Audio Stack calls the BLE_AUDIO_STACK_NotifyToRun() to notify the system that the BLE_AUDIO_STACK_Task() function should be executed. Note the BLE_AUDIO_STACK_Task() shall not be executed in the BLE_AUDIO_STACK_NotifyToRun() context.
The BLE Audio Process Stack is initialized with the BLE_AUDIO_STACK_Init() API call.
The BLE_AUDIO_STACK_NotifyToRun() API shall be implemented in the project.
Bluetooth® LE Audio Stack Integration Dependency - Bare Metal Sequencer / Operation System |
---|
The BLE Audio Stack Sequencer and Initialization APIs are declared in ble_audio_stack.h header file in the Middlewares\ST\STM32_WPAN\ble\audio\Inc folder.
Functions | Header File |
---|---|
void BLE_AUDIO_STACK_Init(void)
|
ble_audio_stack.h |
void BLE_AUDIO_STACK_NotifyToRun(void)
|
ble_audio_stack.h |
void BLE_AUDIO_STACK_Task(void)
|
ble_audio_stack.h |
2.7. Non-Volatile Memory Manager
The Bluetooth® LE Audio Stack requires Non-Volatile Memory services access to manage BLE Audio Databases associated to the ATT services of the BLE Audio Profiles composing the Generic Audio Framework.
The Bluetooth® LE Audio Stack requires functions to read/write/compare/erase information in Non-Volatile Memory. For this, the Bluetooth® LE Audio stack calls the following APIs:
- BLE_AUDIO_PLAT_NvmAdd()
- BLE_AUDIO_PLAT_NvmGet()
- BLE_AUDIO_PLAT_NvmCompare()
- BLE_AUDIO_PLAT_NvmDiscard()
These APIs shall be implemented in the project.
In order to retrieve data stored in Non-Volatile Memory dedicated to each profiles included in the Generic Audio Framework, the Bluetooth® LE Audio Stack enumerates specific NVM types (in ble_audio_if.h header file) in addition to the types declared in ble_plat.h for the BLE Host (BLEPLAT_NVM_TYPE_SEC & BLEPLAT_NVM_TYPE_GATT):
enum
{
BLEAUDIO_PLAT_NVM_TYPE_BAP_PACS = 2,
BLEAUDIO_PLAT_NVM_TYPE_BAP_ASCS = 3,
BLEAUDIO_PLAT_NVM_TYPE_BAP_BASS = 4,
BLEAUDIO_PLAT_NVM_TYPE_CCP = 5,
BLEAUDIO_PLAT_NVM_TYPE_CSIP = 6,
BLEAUDIO_PLAT_NVM_TYPE_MCP = 7,
BLEAUDIO_PLAT_NVM_TYPE_VCP = 8,
BLEAUDIO_PLAT_NVM_TYPE_MICP = 9,
};
Bluetooth® LE Audio Stack Integration Dependency - Non-Volatile Memory Manager |
---|
The BLE Audio NVM APIs are declared in ble_audio_plat.h header file in the Middlewares\ST\STM32_WPAN\ble\audio\Inc folder.
Functions | Header File |
---|---|
int BLE_AUDIO_PLAT_NvmAdd( uint8_t type,const uint8_t* data,uint16_t size,const uint8_t* extra_data,uint16_t extra_size )
|
ble_audio_plat.h |
int BLE_AUDIO_PLAT_NvmGet( uint8_t mode,uint8_t type,uint16_t offset,uint8_t* data,uint16_t size )
|
ble_audio_plat.h |
Int BLE_AUDIO_PLAT_NvmCompare( uint16_t offset,const uint8_t* data,uint16_t size )
|
ble_audio_plat.h |
Int BLE_AUDIO_PLAT_NvmDiscard( uint8_t mode)
|
ble_audio_plat.h |
2.8. Advanced Encryption Standard Module
The Coordinated Set Identification profile in the Generic Audio Framework requires access of many Advanced Encryption Standard operation.
For this, the Bluetooth® LE Audio stack calls the following APIs:
- BLE_AUDIO_PLAT_AesEcbEncrypt()
- BLE_AUDIO_PLAT_AesCmacSetKey()
- BLE_AUDIO_PLAT_AesCmacCompute()
These APIs shall be implemented in the project.
Bluetooth® LE Audio Stack Integration Dependency - Advanced Encryption Standard Module |
---|
The BLE Audio AES APIs are declared in ble_audio_plat.h header file in the Middlewares\ST\STM32_WPAN\ble\audio\Inc folder.
Functions | Header File |
---|---|
void BLE_AUDIO_PLAT_AesEcbEncrypt( const uint8_t* key,const uint8_t* input,uint8_t* output )
|
ble_audio_plat.h |
void BLE_AUDIO_PLAT_AesCmacSetKey( const uint8_t* key )
|
ble_audio_plat.h |
void BLE_AUDIO_PLAT_AesCmacCompute( const uint8_t* input,uint32_t input_length,uint8_t* output_tag )
|
ble_audio_plat.h |
2.9. Random Number Generator Module
The Coordinated Set Identification profile in the Generic Audio Framework requires random number access.
For this, the Bluetooth® LE Audio stack calls the BLE_AUDIO_PLAT_RngGet() API.
This API shall be implemented in the project.
Bluetooth® LE Audio Stack Integration Dependency - Random Number Generator Module |
---|
The BLE Audio RNG API is declared in ble_audio_plat.h header file in the Middlewares\ST\STM32_WPAN\ble\audio\Inc folder.
Functions | Header File |
---|---|
void BLE_AUDIO_PLAT_RngGet( uint8_t n, uint32_t* val )
|
ble_audio_plat.h |
3. Bluetooth® LE Audio Stack Configuration
The Bluetooth® LE Audio Stack is delivered in an unique library supporting all the roles of Profiles composing the Generic Audio Framework.
Nevertheless, the Audio Use Case Profiles, and so the final audio application, are based on Common Audio Profile roles, as defined by the Bluetooth® SIG, which are limited to three types (CAP Acceptor, CAP Commander and CAP Initiator). Each CAP role is associated to specific roles in the sub-profiles composing the Generic Audio Framework as shown in the figure below.
For example, the CAP Acceptor role BAP Unicast Server role but never the BAP Unicast Client role.
Generic Audio Framework- "CAP Role /Profiles" Relationship |
---|
Some mechanisms are available to configure the Bluetooth® LE Audio Stack, and so the Generic Audio Framework, for a specific usage as defined in the Use Case Profiles and so fit just required ROM/RAM resource.
3.1. Configuration of the Audio Profiles of the Generic Audio Framework
The Bluetooth® LE Audio Stack Library offers a dynamic configuration way of its internal Audio Profiles.
Each Audio Profile of the Generic Audio Framework in the BLE Audio Library is independently configurable and the RAM required by each Audio profile Context in the Bluetooth® LE Audio Stack to support its specific configuration shall be allocated in application layer according to the configuration settings.
The RAM context allocation and the configuration of each Audio Profiles of the Generic Audio Framework is performed with CAP_Init() function thanks to the following dedicated Audio Profiles configuration structure parameters :
- CAP_Config_t
- BAP_Config_t
- CCP_Config_t
- MCP_Config_t
- CSIP_Config_t
- VCP_Config_t
- MICP_Config_t
Each of these Configuration structure is composed of :
- configuration setting fields (role, Max Number of BLE Links, specific Audio Profiles settings)
- Settings of the RAM buffer allocated for profile Contexts memory resource
3.1.1. Media Control Profile Configuration Example
The example below describes the field of the Media Control Profile (MCP) Configuration. The MCP_Config_t structure type is defined in the mcp_types.h
In case of the Audio Use Case Profile is based on a CAP Acceptor role supporting MCP feature (MCP Client role):
- the Role field shall be set to MCP_CLIENT_ROLE
- the MaxNumBleLinks shall be set to the maximum number of connection with remote CAP Initiators the CAP Acceptor would support.
- the Clt field shall be filled in which pStartRamAdd field shall points on a RAM allocated in application layer.
3.1.2. Unicast Server (CAP Acceptor) Configuration Example
The figure below show the fields in the BAP_Config_t structure to configure when Unicast Server feature is activated in CAP Acceptor role. The BAP_Config_t structure type is defined in the bap_types.h
3.1.3. Unicast Client (CAP Initiator) Configuration Example
The figure below show the fields in the BAP_Config_t structure to configure when Unicast Client feature is activated in CAP Initiator role. The BAP_Config_t structure type is defined in the bap_types.h
3.1.4. Broadcast Sink (CAP Acceptor) Configuration Example
The figure below show the fields in the BAP_Config_t structure to configure when Broadcast Sink feature is activated in CAP Acceptor role. The BAP_Config_t structure type is defined in the bap_types.h
3.1.5. Broadcast Source (CAP Initiator) Configuration Example
The figure below show the fields in the BAP_Config_t structure to configure when Broadcast Source feature is activated in CAP Initiator role. The BAP_Config_t structure type is defined in the bap_types.h
3.1.6. Scan Delegator (CAP Acceptor/ CAP Commander) Configuration Example
The figure below show the fields in the BAP_Config_t structure to configure when Scan Delegator feature is activated in CAP Acceptor or CAP Commander role. The BAP_Config_t structure type is defined in the bap_types.h
3.1.7. Broadcast Assistant (CAP Commander) Configuration Example
The figure below show the fields in the BAP_Config_t structure to configure when Broadcast Assistant feature is activated in CAP Commander role. The BAP_Config_t structure type is defined in the bap_types.h
3.2. RAM Context Allocation of the Audio Profiles of the Generic Audio Framework
The Context memory of the Audio Profiles in the Generic Audio Framework is allocated in application layer according to specified Audio Profile configuration submitted over parameters of CAP_Init() API.
Many MACRO and Constants are defined for each Audio Profile to calculate the required RAM size for context resource to support the specified configuration.
Example – Media Control Profile (mcp_types.h) 2 macros are defined to calculate RAM size:
- BLE_MCP_CLT_TOTAL_BUFFER_SIZE() returns the amount of memory, in bytes, needed for the storage of data structures in MCP Client.
- BLE_MCP_SRV_TOTAL_BUFFER_SIZE() returns the amount of memory, in bytes, needed for the storage of data structures in MCP Server
Warning:
The values of the parameters of the MACRO shall be equal to the values of the fields submitted in parameter of the Audio Profiles configuration in CAP_Init().
In case of the parameters don't match, the CAP_Init() could fails because the Audio Stack will fail to allocate memory required by the Audio Profile or the CAP_Init() could unused memory to allocate the context of the Audio Profile.
3.3. GATT Allocation of the Audio Profiles of the Generic Audio Framework
Each Audio Profile in GATT Server role in the Generic Audio Framework requires GATT Service and GATT Attributes allocation.
These allocations are done through the BleStack_init_t type parameter of the BleStack_Init() API of the BLE Host Stack.
MACRO and Constants are defined for each Audio Profiles to calculate the required number of GATT Services and GATT Attributes to support a specified Audio Profile configuration.
Example – Media Control Profile (mcp_types.h)
- MCP_SRV_NUM_GATT_SERVICES(num_media_players) is defined to calculate the number of GATT Services required to configure the Server role of the Media Control Profile according to the number of Media Player Instance which would be registered in application layer.
- MCP_SRV_NUM_GATT_ATTRIBUTES(num_media_players,mcp_feature) is defined to calculate the number of GATT attributes required to configure the Server role of the Media Control Profile according to the number of Media Player Instance and the supported MCP option feature.
3.4. ROM Optimization of the Bluetooth® LE Audio Stack
Because the Bluetooth® LE Audio Stack is delivered in an unique Library, the library supports all the roles of the profiles of the Generic Audio Framework.
Consequently, if the final audio application is based on only limited audio profiles and limited profiles role, a lot of code in the Bluetooth® LE Audio Stack is not used and this memory could not be assigned for application layer implementation.
In order to limit the unused RAM in the Bluetooth® LE Audio Stack, a mechanism, based on weak function concept , has been integrated in the Bluetooth® LE Audio Stack. This mechanism allows to overwrite, in application layer, the functions implemented in the static library which will not be called in a specific use case.
In the Bluetooth® LE Audio Stack , many functions which generate a high ROM allocation for a specific Audio Profile role have been identified and declared as weak function.
In case of the Audio Profile role is not required/supported for the BLE Audio Use Case, the weak function is implemented in application layer as an empty function. By the way, all the ROM allocation generate by the function in the BLE Audio Stack library is removed in the final BLE Audio Use Case implementation.
The figure below shows the weak function defined in the Bluetooth® LE Audio Stack for each role of the Audio Profiles in the Generic Audio Framework.
Example 1
For a BLE Audio Use Case which doesn’t require BAP Unicast Server role, in application layer, the following functions should be overwritten to remove unused code in the BLE Audio Stack Library :
Example 2
For a LE Use Case which doesn’t require MCP Media Control Server role, in application layer, we should implement as following to remove unused code in the BLE Audio Stack Library :
4. Bluetooth® LE Generic Audio Framework Procedures
This section describes the main procedures handled by the CAP layer of the Generic Audio Framework:
- Audio Profiles of the Generic Audio Framework Linkup procedure
- Unicast Audio procedures
- Broadcast Audio procedures
4.1. Audio Profiles Linkup
4.1.1. Profiles of Capture and Rendering Control and Audio Stream Transitions
The Generic Audio Framework implements a CAP Linkup procedure, initiated by calling the CAP_Linkup() function, that shall be called by CAP Initiator or CAP Commander to discover/link the audio profiles supported by remote CAP Acceptor / CAP Commander.
The CAP_Linkup() function performs linkup up operation on profile composing the Capture and Rendering Control and/or the Audio Stream Transition according to the supported profiles role of the local audio device :
- Common Audio Profile
- Coordinated Set Identification Profile
- Basic Audio Profile
- Volume Control Profile
- Microphone Control Profile
Functions | Description | Header File |
---|---|---|
CAP_Linkup() | Perform Linkup operation on CAP, CSIP, BAP, VCP, MICP according to supported roles | cap_types.h |
The events CAP_CSI_LINKUP_EVT, CAP_UNICAST_LINKUP_EVT, CAP_BA_LINKUP_EVT and CAP_VOLUME_CTRL_LINKUP_EVT may notified during the CAP linkup procedure depending on the role supported by the local device and the remote device.
The CAP_LINKUP_COMPLETE_EVT event is notified once CAP procedure is complete.
Events | Description | Header File |
---|---|---|
CAP_UNICAST_LINKUP_EVT | Event notified during CAP linkup procedure if CAP Initiator supports BAP Unicast Client role and discovers that the remote device supports BAP Unicast Server role. | cap_types.h |
CAP_CSI_LINKUP_EVT | Event notified during CAP linkup procedure if CAP Initiator/Commander supports CSIP Set Coordinator role and discovers that the remote device supports CSIP Set Member role. | cap_types.h |
CAP_BA_LINKUP_EVT | Event notified during CAP linkup procedure if CAP Commander supports BAP Broadcast Assistant role and discovers that the remote device supports Scan Delegator role. | cap_types.h |
CAP_VOLUME_CTRL_LINKUP_EVT | Event notified during CAP linkup procedure if CAP Commander supports VCP Volume Controller role and discovers that the remote device supports VCP Volume Renderer role. | cap_types.h |
CAP_MICROPHONE_CTRL_LINKUP_EVT | Event notified during CAP linkup procedure if CAP Commander supports MICP Microphone Controller role and discovers that the remote device supports MICP Microphone Device role. | cap_types.h |
CAP_LINKUP_COMPLETE_EVT | Event notified once CAP Linkup is complete. | cap_types.h |
In case of the remote CAP Acceptor is a Set Member of a Coordinated Set, the local CAP Initiator or CAP Commander should discover and performs CAP Linkup procedure with other CAP Acceptors of the Coordinated Set.
The figure below shows an example of implementation to perform CAP Linkup with all CAP Acceptors of a Coordinated Set.
4.1.2. Profiles of Content Control
The Call Control Profile and Media Control profile linkup is managed by the CAP Acceptor / CAP Commander (in GATT Client role for these profiles) with a remote CAP Initiator.
The CAP Acceptor performs automatic linkup of CCP and MCP during Unicast Audio Start procedure initiated by the remote CAP Initiator. When an Audio Stream Endpoint indicates that a Media Content Control or a Call Content Control is activated/deactivated through the metadata associated to the Audio Stream Endpoint in ENABLING/STREAMING state, the BLE Audio Stack reports CAP events :
Events | Description | Header File |
---|---|---|
CAP_CCP_INST_ACTIVATED_EVT | Event notified when a Telephone Bearer Instance of the Call Control Profile is activated and associated to an Audio Stream. | cap_types.h |
CAP_CCP_INST_DEACTIVATED_EVT | Event notified when a Telephone Bearer Instance of the Call Control Profile is deactivated. | cap_types.h |
CAP_MCP_INST_ACTIVATED_EVT | Event notified when a Media Player Instance of the Media Control Profile is activated and associated to an Audio Stream. | cap_types.h |
CAP_MCP_INST_DEACTIVATED_EVT | Event notified when a Media Player Instance of the Media Control Profile is deactivated. | cap_types.h |
4.2. Audio Stream Transition Procedures
The procedure associated to the Audio Stream Transition are specified in the 7.3.1 chapter of the CAP Specification
4.2.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 following APIs :
Functions | Description | Header File |
---|---|---|
CAP_Unicast_AudioStart() | Start Unicast Audio with specified CAP Acceptors according Sink/ Source Streams 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 CAP Acceptor supporting Unicast Server role has access to many CAP APIS allowing to :
- Register Sink/Source Audio Channels accessible by the remote CAP Initiator
- 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 below describes the functions accessible by the CAP Acceptor in Unicast Server role.
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 context for reception and transmission. | cap.h |
CAP_SetAvailableAudioContexts() | Set/Update available audio context for reception and transmission. | 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 |
The chapter 3.5 Unicast Server support requirements of the BAP Specification describes the requirement of the CAP Acceptor in Unicast Server role concerning the Audio Capabilities configuration and the Audio Channels configuration to support according to the Audio role (Sink and/or Source) and the Audio Locations.
Note that each BLE Audio Use Case profile specifies its Audio Capabilities and Audio Channels requirements.
During the Unicast Audio Stream Transitions procedure, the CAP Initiator and the CAP Acceptor will receive CAP events described in table below.
Events | Description | CAP Initiator | CAP Acceptor |
---|---|---|---|
CAP_UNICAST_AUDIO_STARTED | Unicast Audio Start Procedure is complete. | style="text-align: center: #03234b;">X | |
CAP_UNICAST_PREFERRED_QOS_REQ_EVT | Preferred QoS settings are requested for specified Audio Stream Endpoint. | X |