feat(ble_audio): Support ISO & LE Audio functionalities (Preview)

This commit is contained in:
Linyan Liu
2026-02-25 17:52:10 +08:00
committed by BOT
parent 15a0d3fdea
commit 3ef5da096a
383 changed files with 155035 additions and 5 deletions
+11
View File
@@ -64,6 +64,15 @@ BLE_MESH_DOCS = [
'api-reference/bluetooth/esp-ble-mesh.rst',
]
BLE_ISO_DOCS = [
'api-reference/bluetooth/esp-ble-iso.rst',
]
BLE_AUDIO_DOCS = [
'api-reference/bluetooth/esp-ble-audio.rst',
'api-guides/ble/ble-audio.rst',
]
CLASSIC_BT_DOCS = [
'api-guides/classic-bt/index.rst',
'api-guides/classic-bt/overview.rst',
@@ -343,6 +352,8 @@ conditional_include_dict = {
'SOC_BT_SUPPORTED': BT_DOCS,
'SOC_BLE_SUPPORTED': BLE_DOCS,
'SOC_BLE_MESH_SUPPORTED': BLE_MESH_DOCS,
'SOC_BLE_ISO_SUPPORTED': BLE_ISO_DOCS,
'SOC_BLE_AUDIO_SUPPORTED': BLE_AUDIO_DOCS,
'SOC_BLUFI_SUPPORTED': BLUFI_DOCS,
'SOC_WIFI_SUPPORTED': WIFI_DOCS,
'SOC_BT_CLASSIC_SUPPORTED': CLASSIC_BT_DOCS,
+24
View File
@@ -55,6 +55,30 @@ INPUT = \
$(PROJECT_PATH)/components/bt/esp_ble_mesh/api/models/include/esp_ble_mesh_sensor_model_api.h \
$(PROJECT_PATH)/components/bt/esp_ble_mesh/api/models/include/esp_ble_mesh_time_scene_model_api.h \
$(PROJECT_PATH)/components/bt/esp_ble_mesh/v1.1/api/models/include/esp_ble_mesh_mbt_model_api.h \
$(PROJECT_PATH)/components/bt/esp_ble_audio/api/audio/include/esp_ble_audio_aics_api.h \
$(PROJECT_PATH)/components/bt/esp_ble_audio/api/audio/include/esp_ble_audio_bap_api.h \
$(PROJECT_PATH)/components/bt/esp_ble_audio/api/audio/include/esp_ble_audio_bap_lc3_preset_defs.h \
$(PROJECT_PATH)/components/bt/esp_ble_audio/api/audio/include/esp_ble_audio_cap_api.h \
$(PROJECT_PATH)/components/bt/esp_ble_audio/api/audio/include/esp_ble_audio_ccp_api.h \
$(PROJECT_PATH)/components/bt/esp_ble_audio/api/audio/include/esp_ble_audio_codec_api.h \
$(PROJECT_PATH)/components/bt/esp_ble_audio/api/audio/include/esp_ble_audio_common_api.h \
$(PROJECT_PATH)/components/bt/esp_ble_audio/api/audio/include/esp_ble_audio_csip_api.h \
$(PROJECT_PATH)/components/bt/esp_ble_audio/api/audio/include/esp_ble_audio_defs.h \
$(PROJECT_PATH)/components/bt/esp_ble_audio/api/audio/include/esp_ble_audio_gmap_api.h \
$(PROJECT_PATH)/components/bt/esp_ble_audio/api/audio/include/esp_ble_audio_gmap_lc3_preset_defs.h \
$(PROJECT_PATH)/components/bt/esp_ble_audio/api/audio/include/esp_ble_audio_has_api.h \
$(PROJECT_PATH)/components/bt/esp_ble_audio/api/audio/include/esp_ble_audio_lc3_defs.h \
$(PROJECT_PATH)/components/bt/esp_ble_audio/api/audio/include/esp_ble_audio_mcc_api.h \
$(PROJECT_PATH)/components/bt/esp_ble_audio/api/audio/include/esp_ble_audio_mcs_defs.h \
$(PROJECT_PATH)/components/bt/esp_ble_audio/api/audio/include/esp_ble_audio_media_proxy_api.h \
$(PROJECT_PATH)/components/bt/esp_ble_audio/api/audio/include/esp_ble_audio_micp_api.h \
$(PROJECT_PATH)/components/bt/esp_ble_audio/api/audio/include/esp_ble_audio_pacs_api.h \
$(PROJECT_PATH)/components/bt/esp_ble_audio/api/audio/include/esp_ble_audio_pbp_api.h \
$(PROJECT_PATH)/components/bt/esp_ble_audio/api/audio/include/esp_ble_audio_tbs_api.h \
$(PROJECT_PATH)/components/bt/esp_ble_audio/api/audio/include/esp_ble_audio_tmap_api.h \
$(PROJECT_PATH)/components/bt/esp_ble_audio/api/audio/include/esp_ble_audio_vcp_api.h \
$(PROJECT_PATH)/components/bt/esp_ble_audio/api/audio/include/esp_ble_audio_vocs_api.h \
$(PROJECT_PATH)/components/bt/esp_ble_audio/api/iso/include/esp_ble_iso_common_api.h \
$(PROJECT_PATH)/components/bt/host/bluedroid/api/include/api/esp_a2dp_api.h \
$(PROJECT_PATH)/components/bt/host/bluedroid/api/include/api/esp_avrc_api.h \
$(PROJECT_PATH)/components/bt/host/bluedroid/api/include/api/esp_bt_defs.h \
+2
View File
@@ -55,6 +55,8 @@ These third party libraries can be included into the application (firmware) prod
* :component:`BLE Mesh <bt/esp_ble_mesh>` is adapted from Zephyr Project, Copyright (C) 2017-2018 Intel Corporation and licensed under Apache License 2.0.
* :component:`BLE Audio <bt/esp_ble_audio>` is adapted from Zephyr Project, Copyright (C) 2017-2018 Intel Corporation and licensed under Apache License 2.0.
* `mynewt-nimble`_, Copyright (C) 2015-2018 The Apache Software Foundation, is licensed under Apache License 2.0 as described in :component_file:`LICENSE file <bt/host/nimble/nimble/LICENSE>`.
* `TLSF allocator <https://github.com/espressif/tlsf>`_, Copyright (C) 2006-2016 Matthew Conte, and licensed under the BSD 3-clause license.
+497
View File
@@ -0,0 +1,497 @@
LE Audio Architecture Guide
============================
:link_to_translation:`zh_CN:[中文]`
This document introduces the Bluetooth LE Audio architecture: its profiles, services, the roles they define, and the dependency relationships among them. It is intended as a conceptual reference to help you choose the right set of profiles for your application before working with the :doc:`ESP-BLE-AUDIO API reference <../../api-reference/bluetooth/esp-ble-audio>`.
Overview
--------
Bluetooth LE Audio is a suite of specifications introduced in Bluetooth Core Specification 5.2. It enables high-quality, low-power audio over Bluetooth LE using the following key additions to the standard:
- **LE Isochronous Channels (ISO)** — A new controller-level transport for time-synchronized, low-latency data streams, supporting both connected (CIS) and connectionless (BIS) modes.
- **LC3 Codec** — The Low Complexity Communication Codec, which provides better audio quality at lower bitrates compared to SBC.
- **Generic Audio Framework (GAF)** — A layered set of profiles and services that standardize audio stream setup, volume control, media control, call control, and device coordination.
LE Audio supports two fundamental audio scenarios:
- **Unicast Audio** — Bidirectional or unidirectional audio between two connected devices over Connected Isochronous Streams (CIS). Typical use cases: TWS earbuds, hearing aids, headsets, telephony.
- **Broadcast Audio (Auracast™)** — Unidirectional audio from one broadcaster to any number of receivers over Broadcast Isochronous Streams (BIS). Typical use cases: public venue audio, accessibility assistive listening, group TV listening.
Architecture Overview
---------------------
The LE Audio architecture is organized into three tiers:
1. **LE Isochronous Channels** — The transport layer, providing CIS (connected) and BIS (broadcast) streams.
2. **Generic Audio Framework (GAF)** — The core specification suite, organized into four functional layers: stream control, content control, rendering/capture control, and transition/coordination control.
3. **Use-Case Specific Profiles** — Higher-level profiles (HAP, TMAP, GMAP, PBP) that select and configure specific GAF components for a target use case.
.. code-block:: none
┌──────────────────────────────────────────────────────────────────────┐
│ Use-Case Specific Profiles │
│ HAP TMAP GMAP PBP │
├──────────────────────────────────────────────────────────────────────┤
│ Generic Audio Framework (GAF) │
│ ┌───────────────────────────────────────────────────────────────┐ │
│ │ Transition & CAP + CAS │ │
│ │ Coordination Control CSIP + CSIS │ │
│ ├───────────────────────────────────────────────────────────────┤ │
│ │ Rendering & VCP (VCS, VOCS, AICS) │ │
│ │ Capture Control MICP (MICS, AICS) │ │
│ ├───────────────────────────────────────────────────────────────┤ │
│ │ Content Control MCP + MCS/GMCS │ │
│ │ CCP + TBS/GTBS │ │
│ ├───────────────────────────────────────────────────────────────┤ │
│ │ Stream Control BAP (PACS, ASCS, BASS) │ │
│ └───────────────────────────────────────────────────────────────┘ │
├──────────────────────────────────────────────────────────────────────┤
│ LE Isochronous Channels (CIS / BIS) │
└──────────────────────────────────────────────────────────────────────┘
Each GAF layer depends only on the layers below it. Use-case profiles select a subset of GAF layers and add role-specific constraints on top. The sections below describe each component in detail.
LE Isochronous Channels
-----------------------
LE Isochronous Channels are a feature of the Bluetooth controller, defined in the Bluetooth Core Specification. They provide the time-synchronized, low-latency data transport that LE Audio relies on.
.. list-table::
:header-rows: 1
:widths: 15 15 70
* - Type
- Abbreviation
- Description
* - Connected Isochronous Stream
- CIS
- Bidirectional isochronous link between two devices; requires a prior ACL connection. Multiple CIS instances can be grouped into a Connected Isochronous Group (CIG) for synchronized playback (e.g., left and right earbuds).
* - Broadcast Isochronous Stream
- BIS
- Unidirectional isochronous stream from a Broadcaster to any number of Synchronized Receivers, without a prior connection. Multiple BIS instances belong to a Broadcast Isochronous Group (BIG).
ESP-IDF provides direct access to CIS and BIS via the :doc:`ESP-BLE-ISO API <../../api-reference/bluetooth/esp-ble-iso>`. When using LE Audio profiles (BAP and above), the ISO layer is managed automatically by the profile stack.
Generic Audio Framework
-----------------------
The Generic Audio Framework (GAF) is the core of LE Audio. It defines four functional layers, described below from the bottom up.
Stream Control Layer
^^^^^^^^^^^^^^^^^^^^
The stream control layer is responsible for discovering audio capabilities, setting up audio streams (codec configuration and QoS), and managing the lifecycle of CIS and BIS connections.
**Basic Audio Profile (BAP)**
BAP is the foundational profile for all LE Audio streaming. It defines the following roles:
- **Unicast Client** — Discovers ASEs on a remote Unicast Server, initiates codec configuration, QoS negotiation, and stream control (enable, connect, start, disable, release).
- **Unicast Server** — Exposes audio endpoints (ASEs) via ASCS and responds to client-initiated stream control procedures.
- **Broadcast Source** — Creates a BIG, configures BIS streams, and sends audio data.
- **Broadcast Sink** — Scans for and synchronizes to a Broadcast Source, receives BIS audio data.
- **Broadcast Assistant** — Scans for Broadcast Sources on behalf of a low-power Scan Delegator and writes the results to BASS on the delegator.
- **Scan Delegator** — Exposes BASS and delegates BIS scanning to a Broadcast Assistant.
BAP depends on three GATT services:
.. list-table::
:header-rows: 1
:widths: 35 65
* - Service
- Role
* - Published Audio Capabilities Service (PACS)
- Exposes the device's supported codecs, codec configurations, and available audio contexts. Present on both Unicast Server and Broadcast Sink.
* - Audio Stream Control Service (ASCS)
- Exposes one or more Audio Stream Endpoints (ASEs), each representing a sink or source data path. Present on the Unicast Server only.
* - Broadcast Audio Scan Service (BASS)
- Used by the Scan Delegator to expose receive state; written by the Broadcast Assistant with Broadcast Source information. Present on the Scan Delegator only.
Content Control Layer
^^^^^^^^^^^^^^^^^^^^^
The content control layer provides standardized control over the media content and telephony activity that is being rendered by the audio stream.
**Media Control Profile (MCP) and Media Control Service (MCS)**
MCP defines a **Media Control Server** (which exposes a media player via MCS) and a **Media Control Client** (which discovers and controls the player). MCS exposes media state (playing/paused/stopped), playback position, track metadata, and control point operations (play, pause, next track, seek, etc.).
MCS comes in two forms:
- **MCS** — Per-player instance, for devices with multiple concurrent media players.
- **Generic MCS (GMCS)** — A single mandatory instance that provides access to the currently active player, used by clients that do not need per-player granularity.
MCP can optionally depend on the **Object Transfer Profile (OTP)** and **Object Transfer Service (OTS)** for transferring media objects (track names, icons, object metadata) when the device supports it.
**Call Control Profile (CCP) and Telephone Bearer Service (TBS)**
CCP defines a **Call Control Server** (which exposes one or more telephone bearers via TBS) and a **Call Control Client** (which discovers and controls calls). TBS exposes call state, call URI schemes, incoming/outgoing call control, signal strength, and provider name.
TBS comes in two forms:
- **TBS** — Per-bearer instance for devices with multiple telephony bearers (e.g., separate SIM cards or VoIP applications).
- **Generic TBS (GTBS)** — A single mandatory instance that provides a unified view of all bearers.
Rendering and Capture Control Layer
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The rendering and capture control layer provides standardized control over the audio output level and audio input gain of a device, independent of the content being played.
**Volume Control Profile (VCP)**
VCP defines a **Volume Renderer** (which exposes volume state and accepts remote control) and a **Volume Controller** (which discovers and controls the renderer). VCP depends on the following GATT services:
.. list-table::
:header-rows: 1
:widths: 35 15 50
* - Service
- Required
- Description
* - Volume Control Service (VCS)
- Mandatory
- Exposes volume setting (0255), mute state, and a volume control point for absolute or relative volume changes.
* - Volume Offset Control Service (VOCS)
- Optional
- Allows per-output volume offset adjustment (e.g., different offsets for left and right channel outputs). A VCS may include one or more VOCS instances.
* - Audio Input Control Service (AICS)
- Optional
- Allows control of audio input gain and mute state for one audio input (e.g., microphone). A VCS may include one or more AICS instances.
**Microphone Control Profile (MICP)**
MICP defines a **Microphone Device** (which exposes microphone state) and a **Microphone Controller** (which discovers and mutes/unmutes it). MICP depends on the following GATT services:
.. list-table::
:header-rows: 1
:widths: 35 15 50
* - Service
- Required
- Description
* - Microphone Control Service (MICS)
- Mandatory
- Exposes the microphone mute state and a mute control point. Present on the Microphone Device.
* - Audio Input Control Service (AICS)
- Optional
- Allows control of audio input gain for specific inputs. A MICS may include one or more AICS instances.
.. note::
AICS is a shared service: it can be included by both VCS (as part of VCP) and MICS (as part of MICP), each as independent instances with separate handles.
Transition and Coordination Control Layer
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The transition and coordination control layer is the top of the GAF. It coordinates audio procedures across multiple devices acting as a group (e.g., a pair of TWS earbuds, or a room of speakers).
**Common Audio Profile (CAP)**
CAP is the top-level profile that defines how a single initiating device can coordinate audio operations (stream setup, volume control, microphone control) across one or more target devices. It defines three roles:
- **CAP Acceptor** — A device that accepts audio streams and volume/microphone control from a CAP Initiator or Commander. A CAP Acceptor shall support BAP Unicast Server or BAP Broadcast Sink (or both), and VCP Volume Renderer. MICP Microphone Device is optional.
- **CAP Initiator** — A device that discovers CAP Acceptors and initiates unicast or broadcast audio procedures using BAP, VCP, and MICP on one or more acceptors simultaneously.
- **CAP Commander** — A device that issues coordinated volume and microphone control commands to one or more CAP Acceptors without managing audio streams directly.
CAP depends on the **Common Audio Service (CAS)**, a mandatory GATT service on every CAP Acceptor. CAS is used for coordinated set member announcement and provides a stable discovery anchor for the CAP Initiator/Commander.
CAP also uses **CSIP** (described below) to identify and address the members of a coordinated set as a group.
**Coordinated Set Identification Profile (CSIP)**
CSIP defines how a group of devices (a "coordinated set") can be discovered and identified as belonging together. A common example is a left/right earbud pair: each earbud is a **CSIP Set Member** and a phone or source device is a **CSIP Set Coordinator**.
CSIP depends on the **Coordinated Set Identification Service (CSIS)**, which exposes:
- A **Set Identity Resolving Key (SIRK)** — Used by the Set Coordinator to match devices belonging to the same set, even across re-advertisements.
- **Set Size** — The number of members in the set.
- **Member Rank** — The rank of this device within the set (used for ordered operations).
Use-Case Specific Profiles
---------------------------
Use-case specific profiles sit on top of the GAF. Each profile selects a specific subset of GAF profiles, defines role-specific configuration constraints (e.g., codec parameters, QoS settings), and may add its own small GATT service for role advertisement.
**Hearing Access Profile (HAP)**
HAP targets hearing aid devices. It adds the concept of **hearing aid presets**: named audio configurations (e.g., "Outdoor", "Restaurant") that the user can select. HAP defines:
- **Hearing Aid** — Implements all GAF roles needed for audio reception, volume control, and (for binaural hearing aid pairs) coordinated set membership.
- **Hearing Aid Unicast Client** — Discovers hearing aids, controls presets, and manages unicast audio streams.
HAP depends on the **Hearing Access Service (HAS)** for preset read/write operations and on BAP, PACS, VCP, MICP, and CSIP from the GAF.
**Telephony and Media Audio Profile (TMAP)**
TMAP defines interoperability configurations for telephony and media use cases. It defines six roles:
.. list-table::
:header-rows: 1
:widths: 20 20 60
* - Role
- Abbreviation
- Description
* - Call Gateway
- CG
- Controls calls on a remote CT using CCP/TBS. Sends and receives bidirectional audio over CIS.
* - Call Terminal
- CT
- Exposes calls via TBS; receives and sends bidirectional audio over CIS.
* - Unicast Media Sender
- UMS
- Sends unidirectional media audio to one or more UMRs over CIS. Acts as BAP Unicast Client and MCP server.
* - Unicast Media Receiver
- UMR
- Receives media audio from a UMS over CIS. Acts as BAP Unicast Server and VCP Volume Renderer.
* - Broadcast Media Sender
- BMS
- Sends media audio to any number of BMRs over BIS. Acts as BAP Broadcast Source.
* - Broadcast Media Receiver
- BMR
- Receives media audio from a BMS over BIS. Acts as BAP Broadcast Sink.
TMAP advertises its roles via the **Telephony and Media Audio Service (TMAS)**, a small GATT service containing a single TMAP Role characteristic. This allows a remote device to discover which TMAP roles the local device supports before establishing a connection. TMAP itself does not define new audio transport mechanisms; it delegates entirely to BAP (for stream setup), VCP (for volume), MCP/MCS (for media control in UMS/UMR), and CCP/TBS (for call control in CG/CT).
**Gaming Audio Profile (GMAP)**
GMAP targets gaming audio products with parameters tuned for lower transport latency and fewer retransmissions. It defines four roles:
.. list-table::
:header-rows: 1
:widths: 20 20 60
* - Role
- Abbreviation
- Description
* - Unicast Game Gateway
- UGG
- Sends game audio to UGTs and optionally receives voice audio back. Acts as BAP Unicast Client.
* - Unicast Game Terminal
- UGT
- Receives game audio from a UGG and optionally sends voice audio back. Acts as BAP Unicast Server.
* - Broadcast Game Sender
- BGS
- Sends game audio over BIS. Acts as BAP Broadcast Source.
* - Broadcast Game Receiver
- BGR
- Receives game audio over BIS. Acts as BAP Broadcast Sink.
GMAP advertises roles via the **Gaming Audio Service (GMAS)** and depends on BAP for stream setup and VCP for volume control.
**Public Broadcast Profile (PBP)**
PBP standardizes the metadata format used by a public broadcast source so that any compatible receiver can discover and synchronize to it without prior pairing. It defines:
- **Public Broadcast Source** — Advertises Auracast™ audio streams with standardized extended advertising data including the Broadcast Audio Announcement and Public Broadcast Announcement. Delegates to BAP Broadcast Source for BIS setup.
- **Public Broadcast Sink** — Scans for PBP sources, reads the announcement metadata to determine audio quality and content, and synchronizes to the BIG. Delegates to BAP Broadcast Sink.
PBP depends entirely on BAP for the underlying broadcast transport; it does not define a new GATT service.
Profile and Service Dependency Reference
-----------------------------------------
The following tables summarize the dependencies between profiles and services in the ESP-IDF LE Audio implementation.
Profile-to-Service Dependencies
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. list-table::
:header-rows: 1
:widths: 22 20 58
* - Profile
- Depends on (Services)
- Notes
* - BAP
- PACS, ASCS, BASS
- PACS on Unicast Server and Broadcast Sink; ASCS on Unicast Server only; BASS on Scan Delegator only.
* - VCP
- VCS (mandatory), VOCS (optional), AICS (optional)
- VOCS and AICS are sub-included services within VCS; each may have multiple instances.
* - MICP
- MICS (mandatory), AICS (optional)
- AICS is a sub-included service within MICS.
* - CAP
- CAS (mandatory)
- CAS must be present on every CAP Acceptor. CAP also uses BAP, VCP, MICP, and CSIP procedures.
* - CSIP
- CSIS (mandatory)
- CSIS on the Set Member device.
* - MCP
- MCS / GMCS (mandatory), OTS (optional)
- GMCS is the single mandatory generic instance; per-player MCS instances are optional. OTS is used when media objects are available.
* - CCP
- TBS / GTBS (mandatory)
- GTBS is the single mandatory generic instance; per-bearer TBS instances are optional.
* - HAP
- HAS (mandatory)
- HAS for preset control. HAP also mandates BAP, PACS, VCP, MICP, and CSIP (for binaural sets).
* - TMAP
- TMAS (mandatory)
- TMAS contains only the TMAP Role characteristic. TMAP delegates stream and control operations to BAP, VCP, MCP, and CCP.
* - GMAP
- GMAS (mandatory)
- GMAS contains only the GMAP Role characteristic. GMAP delegates to BAP and VCP.
* - PBP
- None (no dedicated service)
- PBP uses BAP Broadcast Source/Sink and standardized extended advertising metadata only.
Profile-to-Profile Dependencies
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. list-table::
:header-rows: 1
:widths: 22 22 56
* - Profile
- Depends on (Profiles)
- Notes
* - CAP Initiator / Commander
- BAP, VCP, MICP, CSIP
- Uses BAP for stream setup, VCP and MICP for rendering/capture control, CSIP to address a coordinated set of Acceptors.
* - HAP
- BAP, VCP, MICP, CSIP, CAP
- CAP Acceptor role is mandatory on Hearing Aid devices. CSIP is required for binaural hearing aid pairs.
* - TMAP CG / CT
- BAP (unicast), VCP, CCP
- CG also acts as MCP server (media proxy) in some implementations.
* - TMAP UMS / UMR
- BAP (unicast), VCP, MCP
- —
* - TMAP BMS / BMR
- BAP (broadcast), VCP
- —
* - GMAP UGG / UGT
- BAP (unicast), VCP
- —
* - GMAP BGS / BGR
- BAP (broadcast), VCP
- —
* - PBP Source / Sink
- BAP (broadcast)
- —
Typical Use-Case Profiles
^^^^^^^^^^^^^^^^^^^^^^^^^^
The table below maps common product types to the profiles they require.
.. list-table::
:header-rows: 1
:widths: 30 70
* - Product Type
- Required Profiles / Roles
* - TWS Earbuds (receiver side)
- CAP Acceptor, BAP Unicast Server, VCP Volume Renderer, CSIP Set Member, MICP Microphone Device (if mic present)
* - Phone / Audio Source
- CAP Initiator, BAP Unicast Client, VCP Volume Controller, CSIP Set Coordinator
* - Hearing Aid
- HAP Hearing Aid, CAP Acceptor, BAP Unicast Server, VCP Volume Renderer, CSIP Set Member (for binaural pair)
* - TV / Broadcast Source
- BAP Broadcast Source, PBP Public Broadcast Source (for Auracast™)
* - Hearing Loop Receiver
- BAP Broadcast Sink, PBP Public Broadcast Sink
* - Telephony Headset
- TMAP CT + UMR (or CG + UMS for gateway side), VCP, CCP
* - Gaming Headset
- GMAP UGT (receiver), BAP Unicast Server, VCP Volume Renderer
* - Media Sender (audio bar)
- TMAP UMS (or BMS for broadcast), BAP, MCP/MCS server, VCP
ESP-IDF Implementation
-----------------------
ESP-IDF provides two API components for LE Audio:
- :doc:`ESP-BLE-ISO <../../api-reference/bluetooth/esp-ble-iso>` — Direct access to LE Isochronous Channels (CIS/BIS) for applications that manage their own ISO data paths.
- :doc:`ESP-BLE-AUDIO <../../api-reference/bluetooth/esp-ble-audio>` — High-level LE Audio profile and service APIs covering the full GAF stack (BAP, CAP, VCP, MICP, CSIP, MCP, CCP, HAP, GMAP, TMAP, PBP) and codec support (LC3).
For most applications, ESP-BLE-AUDIO is the correct starting point. ESP-BLE-ISO is intended for advanced use cases that require direct ISO control below the profile layer.
Feature Support
^^^^^^^^^^^^^^^
The table below lists the LE Audio profiles and services currently supported in ESP-IDF.
.. list-table::
:header-rows: 1
:widths: 28 12 60
* - Profile / Service
- Supported
- Notes
* - LE Isochronous Channels (CIS / BIS)
- Yes
- Direct ISO access via :doc:`ESP-BLE-ISO <../../api-reference/bluetooth/esp-ble-iso>`.
* - BAP
- Yes
- All six BAP roles: Unicast Client, Unicast Server, Broadcast Source, Broadcast Sink, Broadcast Assistant, Scan Delegator.
* - PACS
- Yes
- Used by BAP Unicast Server and Broadcast Sink.
* - ASCS
- Yes
- Used by BAP Unicast Server.
* - BASS
- Yes
- Used by BAP Scan Delegator and Broadcast Assistant.
* - CAP
- Yes
- All three CAP roles: Acceptor, Initiator, Commander.
* - CAS
- Yes
- Mandatory service on CAP Acceptors.
* - CSIP / CSIS
- Yes
- Set Member and Set Coordinator roles.
* - VCP / VCS
- Yes
- Volume Renderer and Volume Controller roles.
* - VOCS
- Yes
- Per-output volume offset control; included in VCS as an optional sub-service.
* - AICS
- Yes
- Audio input control; included in VCS and MICS as an optional sub-service.
* - MICP / MICS
- Yes
- Microphone Device and Microphone Controller roles.
* - MCP / MCS
- Partial
- Media Control Server and Media Control Client roles are supported. OTP/OTS-based media object transfer is not currently supported.
* - CCP / TBS
- Yes
- Call Control Server and Call Control Client roles, including GTBS and per-bearer TBS.
* - HAP / HAS
- Yes
- Hearing Aid and Hearing Aid Unicast Client roles, including preset read/write via HAS.
* - TMAP / TMAS
- Yes
- All six TMAP roles: CG, CT, UMS, UMR, BMS, BMR.
* - GMAP / GMAS
- Yes
- All four GMAP roles: UGG, UGT, BGS, BGR.
* - PBP
- Yes
- Public Broadcast Source and Public Broadcast Sink roles.
* - OTP / OTS
- No
- Object Transfer Profile/Service (used by MCP/MCS for media object transfer) is not currently supported.
+1
View File
@@ -46,3 +46,4 @@ Profile
:SOC_BLE_MESH_SUPPORTED: ../esp-ble-mesh/ble-mesh-index
:SOC_BLUFI_SUPPORTED: blufi
:SOC_BLE_AUDIO_SUPPORTED: ble-audio
+26
View File
@@ -58,48 +58,64 @@ The table below shows whether the Bluetooth LE modules are supported in a specif
- ESP-Bluedroid
- ESP-NimBLE
- ESP-BLE-MESH
- ESP-BLE-ISO
- ESP-BLE-AUDIO
- BluFi
* - ESP32
- Y
- Y
- Y
- Y
- \
- \
- Y
* - ESP32-S3
- Y
- Y
- Y
- Y
- \
- \
- Y
* - ESP32-C2
- Y
- Y
- Y
- \
- \
- \
- Y
* - ESP32-C3
- Y
- Y
- Y
- Y
- \
- \
- Y
* - ESP32-C5
- Y
- Y
- Y
- Y
- \
- \
- Y
* - ESP32-C6
- Y
- Y
- Y
- Y
- \
- \
- Y
* - ESP32-C61
- Y
- Y
- Y
- Y
- \
- \
- Y
* - ESP32-H2
- Y
@@ -107,6 +123,16 @@ The table below shows whether the Bluetooth LE modules are supported in a specif
- Y
- Y
- \
- \
- \
* - ESP32-H4
- Y
- Y
- Y
- Y
- Y
- Y
- \
The following sections briefly describe each layer and provide quick links to the related documents and application examples.
@@ -0,0 +1,241 @@
ESP-BLE-AUDIO
=============
ESP-BLE-AUDIO provides APIs for Bluetooth LE Audio, enabling time-synchronized audio over BLE using the Bluetooth Core Specification LE Audio architecture. Applications can implement unicast (one-to-one) and broadcast audio scenarios, including hearing aids, headsets, speakers, and broadcast sources/sinks.
The LE Audio stack is built on the **Bluetooth Core** and the **LC3** codec. The **generic audio framework** includes the Common Audio Profile (CAP), Common Audio Service (CAS), and the profiles and services below. **Use case specific profiles** (HAP, GMAP, TMAP, PBP) sit on top of the generic framework. LE Audio runs over the LE Isochronous Channels (CIS/BIS) supported by :doc:`esp-ble-iso`.
.. warning::
This is a **preview release**. The ESP-BLE-AUDIO APIs, data structures, and configuration parameters are subject to change in future releases. Breaking changes — such as renamed or restructured types, modified function signatures, or removed fields — may be introduced without prior notice.
**Generic audio framework**
* **Common Audio Profile (CAP)** — Top-level profile for coordinating audio procedures across single or multiple devices.
* **Common Audio Service (CAS)** — GATT service companion to CAP; used for coordinated set member announcement.
* **Basic Audio Profile (BAP)** — Unicast and broadcast stream setup, codec configuration, and stream control.
* **Published Audio Capabilities Service (PACS)** — Advertising and negotiating audio capabilities.
* **Audio Stream Control Service (ASCS)** — Exposes sink/source audio endpoints on a BAP Unicast Server; used by the Unicast Client to configure and control streams.
* **Broadcast Audio Scan Service (BASS)** — Allows a Broadcast Assistant to offload BIS scanning from a low-power Scan Delegator.
* **Volume Control Profile (VCP)** — Volume control (VCS, VOCS, AICS).
* **Volume Offset Control Service (VOCS)** — Per-output volume offset.
* **Audio Input Control Service (AICS)** — Audio input (microphone) state and gain.
* **Microphone Control Profile (MICP)** — Microphone mute and gain (MICS).
* **Coordinated Set Identification Profile (CSIP)** — Set member identification for coordinated sets (e.g., left/right earbuds).
* **Media Control Profile (MCP)** — Media control (MCS).
* **Media Control Service (MCS)** — Media control service.
* **Call Control Profile (CCP)** — Call/telephony control (TBS).
* **Telephone Bearer Service (TBS)** — Telephony bearer and in-call control.
* **Media Proxy** — Media proxy service (Zephyr implementation component; not a Bluetooth SIG specification).
**Use case specific profiles**
* **Hearing Access Profile (HAP)** — Hearing aid presets and presets control.
* **Gaming Audio Profile (GMAP)** — Gaming audio (e.g. Unicast Game Gateway/Terminal, Broadcast Game Sender/Receiver).
* **Telephony and Media Audio Profile (TMAP)** — Interoperability configurations for telephony and media audio use cases.
* **Public Broadcast Profile (PBP)** — Discovery and subscription to public broadcast streams.
Application Examples
--------------------
* **BAP (Basic Audio Profile)**
* :example:`bluetooth/esp_ble_audio/bap/broadcast_sink` demonstrates how to act as a BAP Broadcast Sink that synchronizes to a broadcast source and receives BIS audio streams.
* :example:`bluetooth/esp_ble_audio/bap/broadcast_source` demonstrates how to act as a BAP Broadcast Source that creates a BIG and sends broadcast audio over BIS.
* :example:`bluetooth/esp_ble_audio/bap/unicast_client` demonstrates how to discover and connect to a unicast server and establish BAP unicast streams.
* :example:`bluetooth/esp_ble_audio/bap/unicast_server` demonstrates how to advertise and accept unicast connections and serve BAP unicast streams.
* **CAP (Common Audio Profile)**
* :example:`bluetooth/esp_ble_audio/cap/acceptor` demonstrates how to act as a CAP Acceptor for unicast and broadcast flows.
* :example:`bluetooth/esp_ble_audio/cap/initiator` demonstrates how to act as a CAP Initiator for unicast and broadcast flows.
* **TMAP (Telephony and Media Audio Profile)**
* :example:`bluetooth/esp_ble_audio/tmap/bmr` demonstrates the TMAP Broadcast Media Receiver (BMR) role that receives broadcast audio from a BMS.
* :example:`bluetooth/esp_ble_audio/tmap/bms` demonstrates the TMAP Broadcast Media Sender (BMS) role that sends broadcast audio.
* :example:`bluetooth/esp_ble_audio/tmap/central` demonstrates the TMAP Call Gateway (CG) and Unicast Media Sender (UMS) roles.
* :example:`bluetooth/esp_ble_audio/tmap/peripheral` demonstrates the TMAP Call Terminal (CT) and Unicast Media Receiver (UMR) roles.
API Reference
-------------
ESP-BLE-AUDIO APIs are divided into the following parts:
* `Definitions <ESP-BLE-AUDIO Definitions_>`_
* `General Definitions`_
* `LC3 Codec Definitions`_
* `MCS Definitions`_
* `BAP LC3 Preset Definitions`_
* `GMAP LC3 Preset Definitions`_
* `API <ESP-BLE-AUDIO API_>`_
* `Common API`_
* `Codec API`_
* `Common Audio Profile (CAP)`_
* `Call Control Profile (CCP)`_
* `Basic Audio Profile (BAP)`_
* `Published Audio Capabilities (PACS)`_
* `Gaming Audio Profile (GMAP)`_
* `Volume Control Profile (VCP)`_
* `Volume Offset Control Service (VOCS)`_
* `Audio Input Control Service (AICS)`_
* `Microphone Control Profile (MICP)`_
* `Hearing Access Profile (HAP)`_
* `Coordinated Set Identification Profile (CSIP)`_
* `Telephone Bearer Service (TBS)`_
* `Media Control Client (MCC)`_
* `Media Proxy`_
* `Telephony and Media Audio Profile (TMAP)`_
* `Public Broadcast Profile (PBP)`_
ESP-BLE-AUDIO Definitions
-------------------------
This section contains common definitions, constants, and types used across LE Audio.
General Definitions
^^^^^^^^^^^^^^^^^^^
.. include-build-file:: inc/esp_ble_audio_defs.inc
LC3 Codec Definitions
^^^^^^^^^^^^^^^^^^^^^
.. include-build-file:: inc/esp_ble_audio_lc3_defs.inc
MCS Definitions
^^^^^^^^^^^^^^^
.. include-build-file:: inc/esp_ble_audio_mcs_defs.inc
BAP LC3 Preset Definitions
^^^^^^^^^^^^^^^^^^^^^^^^^^
.. include-build-file:: inc/esp_ble_audio_bap_lc3_preset_defs.inc
GMAP LC3 Preset Definitions
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. include-build-file:: inc/esp_ble_audio_gmap_lc3_preset_defs.inc
ESP-BLE-AUDIO API
-----------------
This section contains LE Audio APIs: common helpers, codec, Common Audio Profile (CAP), Call Control Profile (CCP), and all profile/service APIs.
Common API
^^^^^^^^^^
.. include-build-file:: inc/esp_ble_audio_common_api.inc
Codec API
^^^^^^^^^
.. include-build-file:: inc/esp_ble_audio_codec_api.inc
Common Audio Profile (CAP)
^^^^^^^^^^^^^^^^^^^^^^^^^^
.. include-build-file:: inc/esp_ble_audio_cap_api.inc
Call Control Profile (CCP)
^^^^^^^^^^^^^^^^^^^^^^^^^^
.. include-build-file:: inc/esp_ble_audio_ccp_api.inc
Basic Audio Profile (BAP)
^^^^^^^^^^^^^^^^^^^^^^^^^
.. include-build-file:: inc/esp_ble_audio_bap_api.inc
Published Audio Capabilities (PACS)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. include-build-file:: inc/esp_ble_audio_pacs_api.inc
Gaming Audio Profile (GMAP)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. include-build-file:: inc/esp_ble_audio_gmap_api.inc
Volume Control Profile (VCP)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. include-build-file:: inc/esp_ble_audio_vcp_api.inc
Volume Offset Control Service (VOCS)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. include-build-file:: inc/esp_ble_audio_vocs_api.inc
Audio Input Control Service (AICS)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. include-build-file:: inc/esp_ble_audio_aics_api.inc
Microphone Control Profile (MICP)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. include-build-file:: inc/esp_ble_audio_micp_api.inc
Hearing Access Profile (HAP)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. include-build-file:: inc/esp_ble_audio_has_api.inc
Coordinated Set Identification Profile (CSIP)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. include-build-file:: inc/esp_ble_audio_csip_api.inc
Telephone Bearer Service (TBS)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. include-build-file:: inc/esp_ble_audio_tbs_api.inc
Media Control Client (MCC)
^^^^^^^^^^^^^^^^^^^^^^^^^^
.. include-build-file:: inc/esp_ble_audio_mcc_api.inc
Media Proxy
^^^^^^^^^^^
.. include-build-file:: inc/esp_ble_audio_media_proxy_api.inc
Telephony and Media Audio Profile (TMAP)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. include-build-file:: inc/esp_ble_audio_tmap_api.inc
Public Broadcast Profile (PBP)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. include-build-file:: inc/esp_ble_audio_pbp_api.inc
@@ -0,0 +1,41 @@
ESP-BLE-ISO
===========
ESP-BLE-ISO provides APIs for Bluetooth LE Isochronous Channels, enabling time-synchronized, connection-oriented (CIS) and connectionless (BIS) streaming. The implementation is built on the Bluetooth controller ISO support and is intended for use with the :doc:`esp-ble-audio` component.
**Channel types**
* **Connected Isochronous Streams (CIS)** — Bidirectional isochronous links between two devices; requires a prior ACL connection to be established. Used for time-synchronized unicast audio (e.g., LE Audio).
* **Broadcast Isochronous Streams (BIS)** — Unidirectional isochronous streams from a Broadcaster to one or more Synchronized Receivers, without a prior connection. Used for broadcast audio and group listening.
With these APIs you can create or join Connected ISO Groups (CIG), create or synchronize to Broadcast ISO Groups (BIG), set up ISO data paths, and send or receive isochronous data (e.g., LC3 audio). For higher-level LE Audio profiles and codec APIs, see :doc:`esp-ble-audio`.
.. warning::
This is a **preview release**. The ESP-BLE-ISO APIs, data structures, and configuration parameters are subject to change in future releases. Breaking changes — such as renamed or restructured types, modified function signatures, or removed fields — may be introduced without prior notice.
Application Examples
--------------------
* **BIG (Broadcast Isochronous Group)**
- :example:`bluetooth/esp_ble_iso/big_broadcaster` demonstrates how to create a BIG and send isochronous data over BIS.
- :example:`bluetooth/esp_ble_iso/big_receiver` demonstrates how to synchronize to a BIG and receive isochronous data from BIS.
* **CIS (Connected Isochronous Stream)**
- :example:`bluetooth/esp_ble_iso/cis_central` demonstrates how to act as a CIS Central that creates a CIG/CIS and sends isochronous data.
- :example:`bluetooth/esp_ble_iso/cis_peripheral` demonstrates how to act as a CIS Peripheral that accepts a CIS and receives isochronous data.
API Reference
-------------
ESP-BLE-ISO APIs are divided into the following parts:
* `ESP-BLE-ISO Common API`_
ESP-BLE-ISO Common API
----------------------
This section contains macros, type definitions, and functions from ``esp_ble_iso_common_api.h``: BIS index and data path macros, controller delay and interval limits, CIG/BIG parameters and structures, ISO server and channel operations, data path setup, BIG create/sync/terminate, and GAP event types and ISO common initialization.
.. include-build-file:: inc/esp_ble_iso_common_api.inc
+22
View File
@@ -65,6 +65,28 @@ For additional details and API reference from the upstream documentation, refer
esp-ble-mesh
.. only:: SOC_BLE_ISO_SUPPORTED
**ESP-BLE-ISO API**
Bluetooth LE Isochronous Channels (CIS/BIS) for LE Audio and time-synchronized streaming.
.. toctree::
:maxdepth: 1
esp-ble-iso
.. only:: SOC_BLE_AUDIO_SUPPORTED
**ESP-BLE-AUDIO API**
Bluetooth LE Audio profiles and services (BAP, PACS, VCP, HAS, CSIP, etc.).
.. toctree::
:maxdepth: 1
esp-ble-audio
----
Examples and Tutorials
+2
View File
@@ -55,6 +55,8 @@
* :component:`BLE Mesh <bt/esp_ble_mesh>` 改编自 Zephyr 项目,版权归 2017-2018 英特尔公司所有,并根据 Apache License 2.0 进行许可。
* :component:`BLE Audio <bt/esp_ble_audio>` 改编自 Zephyr 项目,版权归 2017-2018 英特尔公司所有,并根据 Apache License 2.0 进行许可。
* `mynewt-nimble`_,版权归 2015-2018 Apache 软件基金会所有,根据 :component_file:`LICENSE 文件 <bt/host/nimble/nimble/LICENSE>` 中描述的 Apache License 2.0 进行许可。
* `TLSF 分配器 <https://github.com/espressif/tlsf>`_,版权归 2006-2016 Matthew Conte 所有,并根据三条款 BSD 许可证进行许可。
+498
View File
@@ -0,0 +1,498 @@
LE Audio 架构指南
==================
:link_to_translation:`en:[English]`
本文介绍低功耗蓝牙 LE Audio 的架构:各规范(Profile)、服务(Service)的定义、它们所包含的角色,以及彼此之间的依赖关系。在使用 :doc:`ESP-BLE-AUDIO API 参考 <../../api-reference/bluetooth/esp-ble-audio>` 进行开发之前,建议先阅读本文,以便选择适合应用场景的规范组合。
概述
----
低功耗蓝牙 LE Audio 是蓝牙核心规范 5.2 引入的一套规范,支持在低功耗蓝牙上传输高质量音频,具备以下核心特性:
- **LE 等时通道(ISO** — 控制器层的新传输机制,提供时间同步、低延迟的数据流,支持已连接(CIS)和无连接(BIS)两种模式。
- **LC3 编解码器** — 低复杂度通信编解码器(Low Complexity Communication Codec),与 SBC 相比,在更低比特率下提供更好的音频质量。
- **通用音频框架(GAF** — 一套分层的规范和服务,标准化了音频流建立、音量控制、媒体控制、通话控制和设备协调等功能。
LE Audio 支持两种基本音频场景:
- **单播音频(Unicast Audio** — 通过连接等时流(CIS)在两个已连接设备之间进行双向或单向音频传输。典型应用:TWS 耳机、助听器、耳麦、电话通信。
- **广播音频(Broadcast AudioAuracast™)** — 通过广播等时流(BIS),由一个广播源向任意数量的接收端进行单向音频传输。典型应用:公共场所音频、无障碍辅助收听、群组电视收听。
架构概览
--------
LE Audio 架构分为三个层次:
1. **LE 等时通道** — 传输层,提供 CIS(已连接)和 BIS(广播)流。
2. **通用音频框架(GAF** — 核心规范套件,分为四个功能层:流控制、内容控制、渲染/采集控制和过渡/协调控制。
3. **特定用例规范** — 更高层的规范(HAP、TMAP、GMAP、PBP),针对特定使用场景选择并配置相应的 GAF 组件。
.. code-block:: none
┌──────────────────────────────────────────────────────────────────────┐
│ 特定用例规范 │
│ HAP TMAP GMAP PBP │
├──────────────────────────────────────────────────────────────────────┤
│ 通用音频框架(GAF) │
│ ┌───────────────────────────────────────────────────────────────┐ │
│ │ 过渡与协调控制层 CAP + CAS │ │
│ │ CSIP + CSIS │ │
│ ├───────────────────────────────────────────────────────────────┤ │
│ │ 渲染与采集控制层 VCPVCS、VOCS、AICS │ │
│ │ MICPMICS、AICS │ │
│ ├───────────────────────────────────────────────────────────────┤ │
│ │ 内容控制层 MCP + MCS/GMCS │ │
│ │ CCP + TBS/GTBS │ │
│ ├───────────────────────────────────────────────────────────────┤ │
│ │ 流控制层 BAPPACS、ASCS、BASS │ │
│ └───────────────────────────────────────────────────────────────┘ │
├──────────────────────────────────────────────────────────────────────┤
│ LE 等时通道(CIS / BIS
└──────────────────────────────────────────────────────────────────────┘
GAF 各层仅依赖其下方的层。特定用例规范选择 GAF 层的子集,并在其之上添加角色特定的约束。以下各节将详细介绍每个组件。
LE 等时通道
-----------
LE 等时通道是蓝牙核心规范中定义的控制器层特性,为 LE Audio 提供时间同步、低延迟的数据传输。
.. list-table::
:header-rows: 1
:widths: 20 15 65
* - 类型
- 缩写
- 说明
* - 连接等时流
- CIS
- 两个设备之间的双向等时链路,需要先建立 ACL 连接。多个 CIS 实例可组成一个连接等时组(CIG),用于同步播放(例如左右耳机)。
* - 广播等时流
- BIS
- 从广播方向任意数量的同步接收方进行的单向等时流,无需事先建立连接。多个 BIS 实例属于一个广播等时组(BIG)。
ESP-IDF 通过 :doc:`ESP-BLE-ISO API <../../api-reference/bluetooth/esp-ble-iso>` 提供对 CIS 和 BIS 的直接访问。使用 LE Audio 规范(BAP 及更高层)时,ISO 层由规范栈自动管理。
通用音频框架(GAF
-------------------
通用音频框架(GAF)是 LE Audio 的核心,定义了四个功能层,下文从下至上依次介绍。
流控制层
^^^^^^^^
流控制层负责发现音频能力、建立音频流(编解码器配置和 QoS)以及管理 CIS 和 BIS 连接的生命周期。
**基本音频规范(BAP**
BAP 是所有 LE Audio 流传输的基础规范,定义了以下角色:
- **单播客户端(Unicast Client** — 发现远端单播服务器上的 ASE,发起编解码器配置、QoS 协商和流控制(使能、连接、开始、禁用、释放)。
- **单播服务器(Unicast Server** — 通过 ASCS 暴露音频端点(ASE),响应客户端发起的流控制流程。
- **广播源(Broadcast Source** — 创建 BIG,配置 BIS 流,发送音频数据。
- **广播接收端(Broadcast Sink** — 扫描并同步至广播源,接收 BIS 音频数据。
- **广播助手(Broadcast Assistant** — 代替低功耗的扫描委托设备扫描广播源,并将结果写入委托设备上的 BASS。
- **扫描委托设备(Scan Delegator** — 暴露 BASS,将 BIS 扫描委托给广播助手。
BAP 依赖三个 GATT 服务:
.. list-table::
:header-rows: 1
:widths: 40 60
* - 服务
- 说明
* - 已发布音频能力服务(PACS
- 暴露设备支持的编解码器、编解码器配置和可用音频上下文。存在于单播服务器和广播接收端。
* - 音频流控制服务(ASCS
- 暴露一个或多个音频流端点(ASE),每个 ASE 代表一个接收或发送数据路径。仅存在于单播服务器。
* - 广播音频扫描服务(BASS
- 由扫描委托设备暴露,用于记录接收状态;由广播助手写入广播源信息。仅存在于扫描委托设备。
内容控制层
^^^^^^^^^^
内容控制层提供对音频流所传输的媒体内容和通话活动的标准化控制。
**媒体控制规范(MCP)与媒体控制服务(MCS)**
MCP 定义了 **媒体控制服务器**\ (通过 MCS 暴露媒体播放器)和 **媒体控制客户端**\ (发现并控制播放器)。MCS 暴露媒体状态(播放中/暂停/停止)、播放位置、曲目元数据以及控制点操作(播放、暂停、下一曲、跳转等)。
MCS 有两种形式:
- **MCS** — 针对拥有多个并发媒体播放器的设备,每个播放器一个实例。
- **通用 MCSGMCS** — 单一必选实例,提供对当前活跃播放器的访问,适用于无需按播放器区分的客户端。
当设备支持媒体对象传输时,MCP 可选依赖 **对象传输规范(OTP****对象传输服务(OTS**,用于传输媒体对象(曲目名称、图标、对象元数据等)。
**通话控制规范(CCP)与电话承载服务(TBS)**
CCP 定义了 **通话控制服务器**\ (通过 TBS 暴露一个或多个电话承载)和 **通话控制客户端**\ (发现并控制通话)。TBS 暴露通话状态、通话 URI 方案、来电/去电控制、信号强度和运营商名称。
TBS 有两种形式:
- **TBS** — 针对拥有多个电话承载(例如多张 SIM 卡或 VoIP 应用)的设备,每个承载一个实例。
- **通用 TBSGTBS** — 单一必选实例,提供所有承载的统一视图。
渲染与采集控制层
^^^^^^^^^^^^^^^^
渲染与采集控制层提供对设备音频输出音量和音频输入增益的标准化控制,独立于所播放的内容。
**音量控制规范(VCP**
VCP 定义了 **音量渲染器(Volume Renderer**\ (暴露音量状态,接受远程控制)和 **音量控制器(Volume Controller**\ (发现并控制渲染器)。VCP 依赖以下 GATT 服务:
.. list-table::
:header-rows: 1
:widths: 35 15 50
* - 服务
- 是否必选
- 说明
* - 音量控制服务(VCS
- 必选
- 暴露音量设置(0–255)、静音状态以及绝对或相对音量控制点。
* - 音量偏移控制服务(VOCS
- 可选
- 支持对每路输出进行音量偏移调整(例如左右声道输出分别设置偏移)。一个 VCS 可包含一个或多个 VOCS 实例。
* - 音频输入控制服务(AICS
- 可选
- 支持对一路音频输入(例如麦克风)的增益和静音状态进行控制。一个 VCS 可包含一个或多个 AICS 实例。
**麦克风控制规范(MICP**
MICP 定义了 **麦克风设备(Microphone Device**\ (暴露麦克风状态)和 **麦克风控制器(Microphone Controller**\ (发现并控制静音/取消静音)。MICP 依赖以下 GATT 服务:
.. list-table::
:header-rows: 1
:widths: 35 15 50
* - 服务
- 是否必选
- 说明
* - 麦克风控制服务(MICS
- 必选
- 暴露麦克风静音状态和静音控制点,存在于麦克风设备端。
* - 音频输入控制服务(AICS
- 可选
- 支持对特定输入的音频输入增益进行控制。一个 MICS 可包含一个或多个 AICS 实例。
.. note::
AICS 是共用服务:VCS(作为 VCP 的一部分)和 MICS(作为 MICP 的一部分)均可包含 AICS,每者各自拥有独立的实例和句柄。
过渡与协调控制层
^^^^^^^^^^^^^^^^
过渡与协调控制层位于 GAF 的最顶层,负责协调作为一个群组运行的多台设备(例如一对 TWS 耳机或一个房间内的多个扬声器)的音频操作。
**通用音频规范(CAP**
CAP 是最高层规范,定义了单个发起设备如何协调一台或多台目标设备执行音频操作(流建立、音量控制、麦克风控制)。它定义了三个角色:
- **CAP 接受端(CAP Acceptor** — 接受来自 CAP 发起端或指挥端的音频流和音量/麦克风控制的设备。CAP 接受端须支持 BAP 单播服务器或 BAP 广播接收端(或两者兼具),以及 VCP 音量渲染器。MICP 麦克风设备为可选。
- **CAP 发起端(CAP Initiator** — 发现 CAP 接受端,并使用 BAP、VCP 和 MICP 同时对一个或多个接受端发起单播或广播音频流程的设备。
- **CAP 指挥端(CAP Commander** — 向一个或多个 CAP 接受端下发协调的音量和麦克风控制指令,但不直接管理音频流的设备。
CAP 依赖 **通用音频服务(CAS**,这是每个 CAP 接受端上的必选 GATT 服务,用于协调集成员通告,为 CAP 发起端/指挥端提供稳定的发现锚点。
CAP 还使用 **CSIP**\ (见下文)对协调集的成员进行识别和集体寻址。
**协调集标识规范(CSIP**
CSIP 定义了如何发现并识别一组设备("协调集")属于同一整体。典型示例是左右耳机对:每个耳机是一个 **CSIP 集成员(Set Member**,手机或音源设备是一个 **CSIP 集协调器(Set Coordinator**
CSIP 依赖 **协调集标识服务(CSIS**,该服务暴露:
- **集身份解析密钥(SIRK** — 用于集协调器匹配属于同一集的设备,即使在重新通告后也有效。
- **集规模(Set Size** — 集中的成员数量。
- **成员排名(Member Rank** — 该设备在集中的排名(用于有序操作)。
特定用例规范
------------
特定用例规范位于 GAF 之上,每个规范选择一部分 GAF 规范,定义针对特定角色的配置约束(例如编解码器参数、QoS 设置),并可添加自己的小型 GATT 服务用于角色通告。
**听力访问规范(HAP**
HAP 面向助听器设备,增加了 **听力预设(Hearing Aid Preset** 的概念:用户可命名的音频配置(例如"室外"、"餐厅"),可在不同场景间切换。HAP 定义了:
- **助听器(Hearing Aid** — 实现音频接收、音量控制以及(双耳助听器对)协调集成员所需的全部 GAF 角色。
- **助听器单播客户端(Hearing Aid Unicast Client** — 发现助听器、控制预设,并管理单播音频流。
HAP 依赖 **听力访问服务(HAS** 进行预设读写操作,同时依赖 GAF 中的 BAP、PACS、VCP、MICP 和 CSIP。
**电话和媒体音频规范(TMAP**
TMAP 为电话和媒体场景定义互操作配置,包含六个角色:
.. list-table::
:header-rows: 1
:widths: 20 10 70
* - 角色
- 缩写
- 说明
* - 通话网关
- CG
- 使用 CCP/TBS 控制远端 CT 上的通话,通过 CIS 收发双向音频。
* - 通话终端
- CT
- 通过 TBS 暴露通话,通过 CIS 收发双向音频。
* - 单播媒体发送方
- UMS
- 通过 CIS 向一个或多个 UMR 发送单向媒体音频,充当 BAP 单播客户端和 MCP 服务器。
* - 单播媒体接收方
- UMR
- 通过 CIS 接收来自 UMS 的媒体音频,充当 BAP 单播服务器和 VCP 音量渲染器。
* - 广播媒体发送方
- BMS
- 通过 BIS 向任意数量的 BMR 发送媒体音频,充当 BAP 广播源。
* - 广播媒体接收方
- BMR
- 通过 BIS 接收来自 BMS 的媒体音频,充当 BAP 广播接收端。
TMAP 通过 **电话和媒体音频服务(TMAS** 通告其角色,该服务是一个包含单一 TMAP 角色特征的小型 GATT 服务,允许远端设备在建立连接前发现本地设备支持的 TMAP 角色。TMAP 本身不定义新的音频传输机制,完全委托给 BAP(流建立)、VCP(音量)、MCP/MCSUMS/UMR 的媒体控制)和 CCP/TBSCG/CT 的通话控制)。
**游戏音频规范(GMAP**
GMAP 面向游戏音频产品,采用针对更低传输延迟和更少重传优化的参数。它定义了四个角色:
.. list-table::
:header-rows: 1
:widths: 22 10 68
* - 角色
- 缩写
- 说明
* - 单播游戏网关
- UGG
- 向 UGT 发送游戏音频,可选接收语音音频,充当 BAP 单播客户端。
* - 单播游戏终端
- UGT
- 接收来自 UGG 的游戏音频,可选发送语音音频,充当 BAP 单播服务器。
* - 广播游戏发送方
- BGS
- 通过 BIS 发送游戏音频,充当 BAP 广播源。
* - 广播游戏接收方
- BGR
- 通过 BIS 接收游戏音频,充当 BAP 广播接收端。
GMAP 通过 **游戏音频服务(GMAS** 通告角色,依赖 BAP 进行流建立,依赖 VCP 进行音量控制。
**公共广播规范(PBP**
PBP 为公共广播源的元数据格式提供标准化定义,使任何兼容的接收方无需配对即可发现并同步该广播流。它定义了:
- **公共广播源(Public Broadcast Source** — 通过标准化扩展通告数据(包含 Broadcast Audio Announcement 和 Public Broadcast Announcement)通告 Auracast™ 音频流,委托 BAP 广播源进行 BIS 建立。
- **公共广播接收端(Public Broadcast Sink** — 扫描 PBP 源,读取通告元数据以确定音频质量和内容,并同步至 BIG,委托 BAP 广播接收端实现。
PBP 完全依赖 BAP 提供底层广播传输,不定义新的 GATT 服务。
规范与服务依赖关系参考
-----------------------
以下表格汇总了 ESP-IDF LE Audio 实现中规范与服务之间的依赖关系。
规范对服务的依赖
^^^^^^^^^^^^^^^^
.. list-table::
:header-rows: 1
:widths: 22 22 56
* - 规范
- 依赖服务
- 说明
* - BAP
- PACS、ASCS、BASS
- PACS 存在于单播服务器和广播接收端;ASCS 仅存在于单播服务器;BASS 仅存在于扫描委托设备。
* - VCP
- VCS(必选)、VOCS(可选)、AICS(可选)
- VOCS 和 AICS 是 VCS 的子包含服务,每类可有多个实例。
* - MICP
- MICS(必选)、AICS(可选)
- AICS 是 MICS 的子包含服务。
* - CAP
- CAS(必选)
- CAS 必须存在于每个 CAP 接受端。CAP 还调用 BAP、VCP、MICP 和 CSIP 的流程。
* - CSIP
- CSIS(必选)
- CSIS 位于集成员设备上。
* - MCP
- MCS / GMCS(必选)、OTS(可选)
- GMCS 是唯一必选的通用实例;按播放器的 MCS 实例为可选。OTS 在设备支持媒体对象时使用。
* - CCP
- TBS / GTBS(必选)
- GTBS 是唯一必选的通用实例;按承载的 TBS 实例为可选。
* - HAP
- HAS(必选)
- HAS 用于预设控制。HAP 还要求 GAF 中的 BAP、PACS、VCP、MICP 和 CSIP(双耳设备)。
* - TMAP
- TMAS(必选)
- TMAS 仅包含 TMAP 角色特征。TMAP 将流和控制操作委托给 BAP、VCP、MCP 和 CCP。
* - GMAP
- GMAS(必选)
- GMAS 仅包含 GMAP 角色特征。GMAP 将操作委托给 BAP 和 VCP。
* - PBP
- 无(无专用服务)
- PBP 仅使用 BAP 广播源/接收端和标准化扩展通告元数据。
规范对规范的依赖
^^^^^^^^^^^^^^^^
.. list-table::
:header-rows: 1
:widths: 25 25 50
* - 规范
- 依赖规范
- 说明
* - CAP 发起端 / 指挥端
- BAP、VCP、MICP、CSIP
- 使用 BAP 建立流,使用 VCP 和 MICP 进行渲染/采集控制,使用 CSIP 寻址协调集成员。
* - HAP
- BAP、VCP、MICP、CSIP、CAP
- 助听器设备上 CAP 接受端角色为强制要求;双耳助听器对需要 CSIP。
* - TMAP CG / CT
- BAP(单播)、VCP、CCP
- CG 在部分实现中还充当 MCP 服务器(媒体代理)。
* - TMAP UMS / UMR
- BAP(单播)、VCP、MCP
- —
* - TMAP BMS / BMR
- BAP(广播)、VCP
- —
* - GMAP UGG / UGT
- BAP(单播)、VCP
- —
* - GMAP BGS / BGR
- BAP(广播)、VCP
- —
* - PBP 源 / 接收端
- BAP(广播)
- —
典型用例所需规范
^^^^^^^^^^^^^^^^
下表将常见产品类型映射到所需的规范和角色。
.. list-table::
:header-rows: 1
:widths: 30 70
* - 产品类型
- 所需规范 / 角色
* - TWS 耳机(接收端)
- CAP 接受端、BAP 单播服务器、VCP 音量渲染器、CSIP 集成员、MICP 麦克风设备(如有麦克风)
* - 手机 / 音源设备
- CAP 发起端、BAP 单播客户端、VCP 音量控制器、CSIP 集协调器
* - 助听器
- HAP 助听器、CAP 接受端、BAP 单播服务器、VCP 音量渲染器、CSIP 集成员(双耳对)
* - 电视 / 广播源
- BAP 广播源、PBP 公共广播源(Auracast™)
* - 听力环路接收端
- BAP 广播接收端、PBP 公共广播接收端
* - 电话耳麦
- TMAP CT + UMR(或网关侧的 CG + UMS)、VCP、CCP
* - 游戏耳机
- GMAP UGT(接收端)、BAP 单播服务器、VCP 音量渲染器
* - 媒体发送端(音响)
- TMAP UMS(或广播场景的 BMS)、BAP、MCP/MCS 服务器、VCP
ESP-IDF 实现
--------------
ESP-IDF 为 LE Audio 提供两个 API 组件:
- :doc:`ESP-BLE-ISO <../../api-reference/bluetooth/esp-ble-iso>` — 直接访问 LE 等时通道(CIS/BIS),适用于需要自行管理 ISO 数据路径的应用。
- :doc:`ESP-BLE-AUDIO <../../api-reference/bluetooth/esp-ble-audio>` — 高层 LE Audio 规范和服务 API,覆盖完整 GAF 栈(BAP、CAP、VCP、MICP、CSIP、MCP、CCP、HAP、GMAP、TMAP、PBP)及编解码器支持(LC3)。
对于大多数应用,ESP-BLE-AUDIO 是正确的起点。ESP-BLE-ISO 适用于需要在规范层之下直接控制 ISO 的高级场景。
功能支持
^^^^^^^^
下表列出了 ESP-IDF 中当前支持的 LE Audio 规范和服务。
.. list-table::
:header-rows: 1
:widths: 28 12 60
* - 规范 / 服务
- 支持状态
- 说明
* - LE 等时通道(CIS / BIS
- 支持
- 通过 :doc:`ESP-BLE-ISO <../../api-reference/bluetooth/esp-ble-iso>` 直接访问 ISO。
* - BAP
- 支持
- 全部六个 BAP 角色:单播客户端、单播服务器、广播源、广播接收端、广播助手、扫描委托端。
* - PACS
- 支持
- 用于 BAP 单播服务器和广播接收端。
* - ASCS
- 支持
- 用于 BAP 单播服务器。
* - BASS
- 支持
- 用于 BAP 扫描委托端和广播助手。
* - CAP
- 支持
- 全部三个 CAP 角色:接受端、发起端、指挥端。
* - CAS
- 支持
- 每个 CAP 接受端上的必选服务。
* - CSIP / CSIS
- 支持
- 集成员和集协调器角色。
* - VCP / VCS
- 支持
- 音量渲染器和音量控制器角色。
* - VOCS
- 支持
- 每路输出的音量偏移控制;作为可选子服务包含在 VCS 中。
* - AICS
- 支持
- 音频输入控制;作为可选子服务包含在 VCS 和 MICS 中。
* - MICP / MICS
- 支持
- 麦克风设备和麦克风控制器角色。
* - MCP / MCS
- 部分支持
- 媒体控制服务器和媒体控制客户端角色已支持。基于 OTP/OTS 的媒体对象传输暂不支持。
* - CCP / TBS
- 支持
- 通话控制服务器和通话控制客户端角色,包括 GTBS 和每承载方 TBS。
* - HAP / HAS
- 支持
- 助听器和助听器单播客户端角色,包括通过 HAS 进行预设读写。
* - TMAP / TMAS
- 支持
- 全部六个 TMAP 角色:CG、CT、UMS、UMR、BMS、BMR。
* - GMAP / GMAS
- 支持
- 全部四个 GMAP 角色:UGG、UGT、BGS、BGR。
* - PBP
- 支持
- 公共广播源和公共广播接收端角色。
* - OTP / OTS
- 不支持
- 对象传输规范/服务(MCP/MCS 用于媒体对象传输)暂不支持。
+1
View File
@@ -46,3 +46,4 @@
:SOC_BLE_MESH_SUPPORTED: ../esp-ble-mesh/ble-mesh-index
:SOC_BLUFI_SUPPORTED: blufi
:SOC_BLE_AUDIO_SUPPORTED: ble-audio
+26
View File
@@ -58,48 +58,64 @@ ESP-IDF 中的低功耗蓝牙协议栈是一个分层架构,可在 {IDF_TARGET
- ESP-Bluedroid
- ESP-NimBLE
- ESP-BLE-MESH
- ESP-BLE-ISO
- ESP-BLE-AUDIO
- BluFi
* - ESP32
- Y
- Y
- Y
- Y
- \
- \
- Y
* - ESP32-S3
- Y
- Y
- Y
- Y
- \
- \
- Y
* - ESP32-C2
- Y
- Y
- Y
- \
- \
- \
- Y
* - ESP32-C3
- Y
- Y
- Y
- Y
- \
- \
- Y
* - ESP32-C5
- Y
- Y
- Y
- Y
- \
- \
- Y
* - ESP32-C6
- Y
- Y
- Y
- Y
- \
- \
- Y
* - ESP32-C61
- Y
- Y
- Y
- Y
- \
- \
- Y
* - ESP32-H2
- Y
@@ -107,6 +123,16 @@ ESP-IDF 中的低功耗蓝牙协议栈是一个分层架构,可在 {IDF_TARGET
- Y
- Y
- \
- \
- \
* - ESP32-H4
- Y
- Y
- Y
- Y
- Y
- Y
- \
以下各节简要介绍了每个层,并提供了相关文档和应用示例的快速链接。
@@ -0,0 +1 @@
.. include:: ../../../en/api-reference/bluetooth/esp-ble-audio.rst
@@ -0,0 +1 @@
.. include:: ../../../en/api-reference/bluetooth/esp-ble-iso.rst
@@ -65,6 +65,28 @@ ESP-IDF 默认的主机协议栈,支持经典蓝牙和低功耗蓝牙。
esp-ble-mesh
.. only:: SOC_BLE_ISO_SUPPORTED
**ESP-BLE-ISO API**
低功耗蓝牙等时通道(CIS/BIS),用于 LE Audio 及时间同步流传输。
.. toctree::
:maxdepth: 1
esp-ble-iso
.. only:: SOC_BLE_AUDIO_SUPPORTED
**ESP-BLE-AUDIO API**
低功耗蓝牙 LE Audio 配置与服务(BAP、PACS、VCP、HAS、CSIP 等)。
.. toctree::
:maxdepth: 1
esp-ble-audio
----
示例与教程