LE Audio 与蓝牙音频

本页介绍杰理 AC792 SDK（release/AC792N_SDK_V3）中 LE Audio（低功耗音频）与蓝牙音频的整体实现：从 TCFG_LE_AUDIO_APP_CONFIG 功能位配置、多协议入口 multi_protocol_main.c 的初始化与事件分发，到 CIS（连接等时流/Unicast）与 BIS（广播等时流/Auracast）两条音频链路，以及它们与经典蓝牙音频（A2DP/HFP/RCSP）在协议栈、音频管线与通话降噪上的协同方式。

Purpose and Scope

本页覆盖以下内容：

LE Audio 在 AC792 SDK 中的使能方式（TCFG_LE_AUDIO_APP_CONFIG 位掩码与 THIRD_PARTY_PROTOCOLS_SEL）
多协议主入口 multi_protocol_main.c 中 LE Audio 的初始化、BLE 安全管理（SM）、RCSP 与 CIS 共用 ACL 的逻辑
CIS（Unicast）与 BIS（Auracast）两条等时音频链路的架构与数据流
LE Audio 在音频层（player/recorder/CVP 降噪）中的接入点

不属于本页范围（留待相关页面）：

RCSP（杰理私有双耳/遥控协议）的完整实现细节 — 本页仅说明其与 CIS 共用 ACL 的耦合点
Auracast 各角色（Receiver/Sink/Assistant/生态）的逐步使用手册 — 仓库文档 cache/V1.0.0/docs/html/_sources/SDK/earphone/mode/earphone_le_audio/ 下已有对应 RST 文档
经典蓝牙 A2DP/HFP 协议本身的编解码细节

Overview

LE Audio 是蓝牙 SIG 基于 LE（低功耗蓝牙）5.2+ 等时信道（Isochronous Channel）定义的下一代音频规范。与经典蓝牙音频（BR/EDR 上的 A2DP/HFP）相比，LE Audio 具备更低的功耗、更高的编解码灵活性（LC3 编码）以及广播音频（Auracast）能力。

AC792 SDK 将 LE Audio 能力组织为两大分支：

CIS / Unicast（单播）：手机等音源与耳机建立一对一（或一对多）连接等时流，用于音乐播放与通话。SDK 中细分为标准 Unicast Sink（LE_AUDIO_UNICAST_SINK_EN）与杰理私有增强版 Unicast Sink（LE_AUDIO_JL_UNICAST_SINK_EN，支持 48kHz/24bit 等扩展采样率）。
BIS / Auracast（广播）：广播源（Source）向不限数量的接收端（Sink/Receiver）单向广播音频，典型场景是机场、商场、助听系统的公共广播。SDK 中细分为 LE_AUDIO_AURACAST_SINK_EN、LE_AUDIO_JL_AURACAST_SINK_EN、LE_AUDIO_AURACAST_SOURCE_EN、LE_AUDIO_JL_AURACAST_SOURCE_EN 等角色。

两种分支共享同一套底层基础设施：LE 协议栈、sdk/audio/le_audio/ 下的 CIG 管理、le_audio_recorder.c/esco_recorder.c 的音频采集、net_file_player.c 的网络音频播放，以及 CVP 通话降噪。这也是本页将"LE Audio 与蓝牙音频"作为一个整体能力来讲述的原因——它们在同一份代码里通过编译期位掩码被统一使能、初始化和调度。

架构

下图展示了 AC792 SDK 中 LE Audio 与蓝牙音频的整体分层架构。所有 LE Audio 子功能都由 TCFG_LE_AUDIO_APP_CONFIG 位掩码统一控制，并在 multi_protocol_main.c 中完成协议栈初始化与事件分发。

flowchart TD
    subgraph sg_App["应用层 apps/common/third_party_profile"]
        MP["multi_protocol_main.c<br/>多协议入口/初始化"]
        ME["multi_protocol_event.c<br/>协议事件分发"]
        MC["multi_protocol_common.c<br/>公共工具"]
    end

    subgraph sg_Config["功能配置"]
        CFG["TCFG_LE_AUDIO_APP_CONFIG 位掩码"]
        BITS["UNICAST_SINK / JL_UNICAST_SINK<br/>AURACAST_SINK / AURACAST_SOURCE"]
        SEL["THIRD_PARTY_PROTOCOLS_SEL"]
    end

    subgraph sg_LEA["LE Audio 协议与链路层 sdk/audio/le_audio"]
        CIG["cig.c<br/>CIG/CIS 管理等时信道"]
        CIS["CIS 链路<br/>Unicast 单播"]
        BIS["BIS 链路<br/>Auracast 广播"]
    end

    subgraph sg_Audio["音频处理管线 sdk/audio"]
        REC["le_audio_recorder.c / esco_recorder.c<br/>上行采集"]
        PLY["net_file_player.c<br/>下行播放"]
        CVP["audio_cvp_config.c<br/>通话降噪 CVP"]
    end

    subgraph sg_Classic["经典蓝牙音频"]
        A2DP["A2DP 音乐"]
        HFP["HFP 通话"]
        RCSP["RCSP 私有协议（与 CIS 共用 ACL）"]
    end

    CFG --> BITS
    BITS --> MP
    SEL --> MP
    MP --> ME
    MP --> CIG
    CIG --> CIS
    CIG --> BIS
    CIS --> REC
    CIS --> PLY
    BIS --> REC
    BIS --> PLY
    REC --> CVP
    RCSP -.->|"get_bt_le_audio_config() 共用 ACL"| CIS
    A2DP --> PLY
    HFP --> CVP

各组件职责：

TCFG_LE_AUDIO_APP_CONFIG（编译期位掩码）：统一开关六种 LE Audio 角色。该宏在多个模块中作为 #if 编译条件出现，例如 multi_protocol_common.c 第 10 行、net_file_player.c 第 1113 行、le_audio_recorder.c 第 38 行，保证只有被使能的角色才编译进固件。
multi_protocol_main.c：多协议栈的唯一初始化入口。根据配置位执行 BLE 通用访问规范（GAP）初始化、BLE 安全管理（SM）初始化（app_ble_sm_init），并在使能 Unicast 时通过 get_bt_le_audio_config() 决定是否让 RCSP 与 CIS 共用同一条 ACL 连接。
cig.c：LE Audio 等时信道管理层，TCFG_LEA_CIG_PERIPHERAL_EN 或 LE_AUDIO_CIS_RX_EN 编译条件下编译，负责 CIG（Connected Isochronous Group）的创建与 CIS 流的承载。
音频管线：CIS/BIS 的播放走 net_file_player.c（与 A2DP 播放器同栈），上行采集走 le_audio_recorder.c（CIS 通话时亦可复用 esco_recorder.c 的 esco_adc 流节点），通话场景经 CVP 降噪配置 audio_cvp_config.c 处理，其中 TCFG_LEA_CALL_DL_GLOBAL_SR 控制 LE Audio 通话下行全局采样率。

架构要点：LE Audio 并非一套孤立的子系统，而是"BLE 协议栈 + 等时信道 + 既有音频播放/采集框架"的组合。这解释了为什么使能 LE Audio 时仍需保留 net_file_player、esco_recorder 等经典蓝牙音频组件——它们被复用以承载 LC3 解码后的 PCM 数据。

主要实现分析

功能使能：`TCFG_LE_AUDIO_APP_CONFIG` 位掩码

整个 SDK 通过一个 32 位编译期掩码 TCFG_LE_AUDIO_APP_CONFIG 统一控制 LE Audio 各角色。从 multi_protocol_common.c 的入口条件可见其用法：

#if THIRD_PARTY_PROTOCOLS_SEL || (TCFG_LE_AUDIO_APP_CONFIG & (LE_AUDIO_UNICAST_SINK_EN | LE_AUDIO_JL_UNICAST_SINK_EN | LE_AUDIO_AURACAST_SINK_EN | LE_AUDIO_JL_AURACAST_SINK_EN | LE_AUDIO_AURACAST_SOURCE_EN | LE_AUDIO_JL_AURACAST_SOURCE_EN))

Source: multi_protocol_common.c

设计意图：将"是否编译多协议/LE Audio 框架"与"具体使能哪种角色"解耦。THIRD_PARTY_PROTOCOLS_SEL 控制是否接入第三方协议栈；TCFG_LE_AUDIO_APP_CONFIG 精确到角色粒度（Sink/Source、标准/杰理增强），使厂商可以按产品形态裁剪固件体积。六个位分别是：

位宏	含义
`LE_AUDIO_UNICAST_SINK_EN`	标准 LE Audio 单播接收端（CIS 下行播放）
`LE_AUDIO_JL_UNICAST_SINK_EN`	杰理增强单播接收端（支持更高采样率，与 RCSP 共存）
`LE_AUDIO_AURACAST_SINK_EN`	Auracast 广播接收端（基础版）
`LE_AUDIO_JL_AURACAST_SINK_EN`	杰理增强 Auracast 接收端
`LE_AUDIO_AURACAST_SOURCE_EN`	Auracast 广播源（基础版）
`LE_AUDIO_JL_AURACAST_SOURCE_EN`	杰理增强 Auracast 广播源

多协议入口 `multi_protocol_main.c`

该文件是 LE Audio 与其它 BLE 协议共存的枢纽。它按配置位分派初始化流程：

BLE SM（安全管理）初始化：当使能 Unicast Sink 时，采用支持 Bonding、Secure Connection 与 MITM 保护的配置：

#elif (TCFG_LE_AUDIO_APP_CONFIG & (LE_AUDIO_UNICAST_SINK_EN | LE_AUDIO_JL_UNICAST_SINK_EN))
    app_ble_sm_init(IO_CAPABILITY_NO_INPUT_NO_OUTPUT, SM_AUTHREQ_BONDING | SM_AUTHREQ_SECURE_CONNECTION | SM_AUTHREQ_MITM_PROTECTION, 7, 0);

Source: multi_protocol_main.c

设计意图：耳机/音箱作为 LE Audio Sink 通常无输入输出能力（IO_CAPABILITY_NO_INPUT_NO_OUTPUT），因此采用 Just Works 配对加 Secure Connection 加密，MITM 保护位在无 I/O 能力下由协议栈降级处理；7 为最大加密密钥长度（128-bit），0 表示无固定密钥。相比 A2DP 无需配对即可连接，LE Audio 强制安全配对，这源于等时信道对内容保护的要求。

ACL 复用决策：Unicast 场景下，杰理私有 RCSP（双耳/遥控）协议与 CIS 共用同一条 ACL 连接：

#if (TCFG_LE_AUDIO_APP_CONFIG & (LE_AUDIO_UNICAST_SINK_EN | LE_AUDIO_JL_UNICAST_SINK_EN))
    if (get_bt_le_audio_config()) { // RCSP 与 CIS 共用 ACL

Source: multi_protocol_main.c

设计意图：TWS 耳机场景中，左右耳与手机之间若分别建立独立的 ACL + CIS，将消耗双倍的连接资源与功耗。get_bt_le_audio_config() 返回运行时配置，决定是否将 RCSP 管理信道与 CIS 数据信道复用在同一条 ACL 上，从而把 BLE 连接数压缩到最少。这是 AC792 SDK 对 LE Audio 单播功耗优化的关键设计。

CIG 管理与 `cig.c`

sdk/audio/le_audio/cig.c 承载 CIG（Connected Isochronous Group）的创建与维护。其编译条件同时覆盖"SDK 原生 LE Audio 外设"与"第三方协议栈 CIS 接收"两种路径：

#if TCFG_LEA_CIG_PERIPHERAL_EN || (THIRD_PARTY_PROTOCOLS_SEL & LE_AUDIO_CIS_RX_EN)

Source: cig.c

设计意图：CIG 是 LE Audio 单播的核心概念——一组 CIS 流的集合，共享同一套时序参数（间隔、事件数、子事件数）。TCFG_LEA_CIG_PERIPHERAL_EN 表示 SDK 自身作为 CIG 外设（Peripheral）侧被使能；LE_AUDIO_CIS_RX_EN 则表示第三方协议栈（如乐鑫/赛普拉斯 LE Audio 方案）接入时以 CIS 接收者身份参与。两条路径最终都收敛到 cig.c 的同一套等时信道管理逻辑，避免协议栈差异导致音频链路重复实现。

下行播放：`net_file_player.c`

LE Audio 解出的 LC3 PCM 数据复用网络文件播放器链路播放。net_file_player.c 第 1112-1114 行的编译条件把 Auracast Sink 与 Unicast Source/Sink 一并纳入其编译范围：

    (TCFG_LE_AUDIO_APP_CONFIG & (LE_AUDIO_AURACAST_SINK_EN | LE_AUDIO_JL_AURACAST_SINK_EN)) || \
    (TCFG_LE_AUDIO_APP_CONFIG & (LE_AUDIO_UNICAST_SOURCE_EN | LE_AUDIO_JL_UNICAST_SOURCE_EN)) || \
    (TCFG_LE_AUDIO_APP_CONFIG & (LE_AUDIO_UNICAST_SINK_EN | LE_AUDIO_JL_UNICAST_SINK_EN))

Source: net_file_player.c

设计意图：A2DP、LE Audio Unicast、Auracast 三者共享同一播放调度框架——"网络/无线流 → 解码 → PCM 输出到 DAC"。复用而非新建播放器，保证了多音源切换（如从 A2DP 切到 Auracast）时音量、EQ、混音等音频后处理链的一致性，也显著减少了代码量与 RAM 占用。

上行采集：`le_audio_recorder.c` 与 `esco_recorder.c`

通话/上行方向，LE Audio 的麦克风采集由 le_audio_recorder.c 承担（编译同样受 TCFG_LE_AUDIO_APP_CONFIG 各角色位与 TCFG_AUDIO_LINEIN_ENABLE 约束，用于 Auracast 广播源等需要本机音频输入的角色）。而在 Unicast 通话场景下，SDK 复用经典蓝牙 eSCO 录音器，将采集流直接挂到 esco_adc 流节点上：

#if ((TCFG_LE_AUDIO_APP_CONFIG & (LE_AUDIO_UNICAST_SINK_EN | LE_AUDIO_JL_UNICAST_SINK_EN)))
    recoder->stream = jlstream_pipeline_parse_by_node_name(uuid, "esco_adc");

Source: esco_recorder.c

设计意图：jlstream_pipeline_parse_by_node_name 按节点名在既有音频流水线中定位 esco_adc（ADC 采集节点），说明 LE Audio 通话并未新建一套麦克风驱动，而是把 HFP 时代的 eSCO ADC 采集链路直接复用。这样做让 AEC（回声消除）等前端算法在 A2DP/HFP 与 LE Audio 通话间完全一致，降低了双栈维护成本。

核心流程

启动初始化流程

下图展示了 LE Audio 使能后固件启动时的协议栈初始化顺序，以及 RCSP/CIS 共用 ACL 的决策点：

sequenceDiagram
    participant Boot as 系统启动
    participant MP as multi_protocol_main.c
    participant SM as BLE 安全管理
    participant CIG as cig.c (CIG/CIS)
    participant RCSP as RCSP 协议
    participant AUD as 音频管线

    Boot->>MP: 进入多协议初始化
    MP->>MP: 检查 TCFG_LE_AUDIO_APP_CONFIG 位掩码
    alt 使能 Unicast Sink (标准/JL)
        MP->>SM: app_ble_sm_init(NoInputNoOutput,<br/>Bonding|SC|MITM, 7, 0)
        SM-->>MP: SM 配置完成
        MP->>MP: get_bt_le_audio_config() == true?
        alt 共用 ACL
            MP->>RCSP: 在既有 ACL 上挂载 RCSP 管理信道
            MP->>CIG: 在同一 ACL 上建立 CIS 等时流
        else 独立连接
            MP->>CIG: 独立建立 ACL + CIS
        end
        CIG-->>AUD: 等时数据就绪，启动 net_file_player 播放
    else 使能 Auracast (Sink/Source)
        MP->>CIG: 配置 BIS 广播/接收
        CIG-->>AUD: 广播流就绪，播放/采集
    end

关键点：

SM 初始化发生在 CIS 建立之前：LE Audio 等时信道要求在加密的 ACL 上承载，因此必须先完成配对加密，再创建 CIS。
get_bt_le_audio_config() 是运行时开关：与编译期位掩码互补，允许同一固件在不同产品配置（例如是否启用 RCSP 双耳功能）下动态决定连接拓扑。
音频链路最后就绪：无论 Unicast 还是 Auracast，等时信道建立成功后才驱动播放器/录音器，避免空流导致的 DAC 爆音。

Unicast 通话数据流

LE Audio 通话（CIS 上行+下行）的实时数据路径：

flowchart LR
    MIC["麦克风"] --> ADC["esco_adc 采集节点<br/>(esco_recorder.c)"]
    ADC --> AEC["AEC 回声消除"]
    AEC --> CVP["CVP 降噪<br/>TCFG_LEA_CALL_DL_GLOBAL_SR 采样率"]
    CVP --> ENC["LC3 编码"]
    ENC --> CIS_UP["CIS 上行等时信道"]

    CIS_DN["CIS 下行等时信道"] --> DEC["LC3 解码"]
    DEC --> PLY["net_file_player.c 播放"]
    PLY --> DAC["DAC 输出"]

设计意图：上行路径在进入 LC3 编码前完成 AEC 与降噪，保证远端听到的是干净语音；下行路径解码后直接进入既有播放框架，与音乐播放共用音量/音效链路。TCFG_LEA_CALL_DL_GLOBAL_SR 控制下行全局采样率——当它不等于 0x01（默认值）时，CVP 参考源（CONST_REF_SRC）配置会为 LE Audio 通话启用额外的全局采样率路径，见 audio_cvp_config.c 第 15 行：

	(((TCFG_LE_AUDIO_APP_CONFIG & (LE_AUDIO_UNICAST_SINK_EN | LE_AUDIO_JL_UNICAST_SINK_EN))) && (defined TCFG_LEA_CALL_DL_GLOBAL_SR) && (TCFG_LEA_CALL_DL_GLOBAL_SR != 0x01))

Source: audio_cvp_config.c

该条件表明：当 LE Audio Unicast 使能且下行采样率非默认时，CVP 的 CONST_REF_SRC（常量参考源）取值为 1，即把 LE Audio 通话下行作为参考信号纳入降噪处理，防止远端语音被当作噪声消除。

数据模型与角色矩阵

LE Audio 在 AC792 SDK 中没有独立数据库，其"数据模型"即编译期角色位与运行时配置的组合：

维度	取值	作用
编译期角色	`TCFG_LE_AUDIO_APP_CONFIG` 六位	决定固件编译进哪些 LE Audio 角色
第三方协议栈	`THIRD_PARTY_PROTOCOLS_SEL`（含 `LE_AUDIO_CIS_RX_EN`）	决定是否走第三方 LE Audio 协议栈
运行时拓扑	`get_bt_le_audio_config()`	决定 RCSP 与 CIS 是否共用 ACL
通话采样率	`TCFG_LEA_CALL_DL_GLOBAL_SR`	决定 CVP 下行参考路径
CIG 外设	`TCFG_LEA_CIG_PERIPHERAL_EN`	决定 SDK 是否作为 CIG Peripheral

CIS 与 BIS 的角色关系：

erDiagram
    ROLE {
        string name "角色名"
        string type "Sink/Source"
    }
    UNICAST {
        string id "CIS 单播"
        string mode "标准/JL 增强"
        bool rcsp_shared "RCSP 共用 ACL"
    }
    AURACAST {
        string id "BIS 广播"
        string mode "Sink/Source"
        string ecology "Receiver/Assistant"
    }
    ROLE ||--o{ UNICAST : "Unicast Sink 角色"
    ROLE ||--o{ AURACAST : "Auracast 角色"
    UNICAST ||--o{ CIG : "承载于 cig.c"
    AURACAST ||--o{ CIG : "共享等时管理"

配置选项

LE Audio 相关的编译期与运行时配置汇总如下。所有 TCFG_* 宏均在工程配置头文件中定义，属于编译期配置；get_bt_le_audio_config() 为运行时查询。

配置项	类型	默认值	说明
`TCFG_LE_AUDIO_APP_CONFIG`	位掩码	0	六位分别使能标准/JL Unicast Sink、Auracast Sink、Auracast Source（见上文角色表）
`THIRD_PARTY_PROTOCOLS_SEL`	位掩码	0	选择第三方协议栈，含 `LE_AUDIO_CIS_RX_EN`（第三方 CIS 接收）
`TCFG_LEA_CIG_PERIPHERAL_EN`	布尔	0	SDK 自身作为 CIG Peripheral 使能（编译 `cig.c` 的 CIS 部分）
`TCFG_LEA_CALL_DL_GLOBAL_SR`	数值	0x01	LE Audio 通话下行全局采样率；非 0x01 时启用 CVP 下行参考路径
`TCFG_AUDIO_LINEIN_ENABLE`	布尔	0	`le_audio_recorder.c` 编译依赖项之一（广播源需本机音频输入）
`get_bt_le_audio_config()`	运行时函数	—	返回 u8，决定 RCSP 与 CIS 是否共用 ACL

配置组合示例（典型产品）：

TWS 耳机（Unicast 通话+音乐）：TCFG_LE_AUDIO_APP_CONFIG = LE_AUDIO_UNICAST_SINK_EN | LE_AUDIO_JL_UNICAST_SINK_EN，TCFG_LEA_CALL_DL_GLOBAL_SR 按通话需求配置，get_bt_le_audio_config() 返回 true 启用 RCSP 共用 ACL。
Auracast 接收音箱：LE_AUDIO_AURACAST_SINK_EN | LE_AUDIO_JL_AURACAST_SINK_EN，无需 SM 配对（广播无连接），编译 net_file_player.c 对应分支。
Auracast 广播源：LE_AUDIO_AURACAST_SOURCE_EN，需 TCFG_AUDIO_LINEIN_ENABLE 提供本机采集输入。

API 参考

以下为 LE Audio 关键入口点（基于源码中已验证的符号）：

`void app_ble_sm_init(u8 io_capability, u16 auth_req, u8 max_key_size, u8 fixed_key)`

BLE 安全管理初始化，multi_protocol_main.c 在 LE Audio Unicast 分支调用。

参数：

io_capability (u8)：I/O 能力，LE Audio Sink 使用 IO_CAPABILITY_NO_INPUT_NO_OUTPUT
auth_req (u16)：认证要求，组合 SM_AUTHREQ_BONDING | SM_AUTHREQ_SECURE_CONNECTION | SM_AUTHREQ_MITM_PROTECTION
max_key_size (u8)：最大密钥长度，取 7（128-bit）
fixed_key (u8)：固定密钥，取 0

`u8 get_bt_le_audio_config(void)`

查询 LE Audio 运行时配置，决定 RCSP 与 CIS 是否共用 ACL。在 multi_protocol_main.c 第 96-97 行声明（extern），由 LE Audio 库实现。

返回： u8，非零表示启用共用 ACL 拓扑。

`stream_obj_t jlstream_pipeline_parse_by_node_name(u8 uuid, const char *node_name)`

在音频流水线中按节点名查找流对象。esco_recorder.c 用它定位 esco_adc 节点，供 LE Audio Unicast 通话上行复用。

参数：

uuid (u8*)：流水线实例标识
node_name (const char*)：节点名，如 "esco_adc"

返回： stream_obj_t* 流对象指针；节点不存在时返回 NULL（调用方需处理）。

失败模式、边界情况与并发

编译期位掩码不一致

TCFG_LE_AUDIO_APP_CONFIG 与 THIRD_PARTY_PROTOCOLS_SEL 必须与产品需求严格匹配。若使能了 LE_AUDIO_UNICAST_SINK_EN 但未使能对应音频组件（如未编译 net_file_player.c 相关分支），可能出现链接期符号缺失或运行时空流。由于这些开关是 #if 编译条件，错误组合通常只能在编译/链接阶段暴露——配置修改后务必全量重编。

配对与连接失败

Sink 使用 NO_INPUT_NO_OUTPUT 能力，依赖 Just Works 配对。若对端（手机）要求 MITM 且无确认路径，配对可能失败或降级——这是无 I/O 耳机设备的固有限制，SDK 通过 SM_AUTHREQ_MITM_PROTECTION 位交由协议栈自动降级。
CIS 必须建立在加密 ACL 之上。若 Bonding 信息丢失（重新配对前），CIS 建立会失败，表现为"能连上但无声"；此时需清除对端配对记录重新配对。

RCSP 共用 ACL 的冲突窗口

get_bt_le_audio_config() 为 true 时，RCSP 与 CIS 共享 ACL。等时流对时序敏感，若 RCSP 管理消息与 CIS 事件在同一连接事件内竞争传输资源，可能引起 CIS 丢包。SDK 依赖 CIG 调度参数（cig.c 中的间隔/子事件配置）为 CIS 预留时隙，调低 CIS 间隔会减少时延但增加功耗与资源占用，需在时延与功耗间权衡。

采样率不匹配

TCFG_LEA_CALL_DL_GLOBAL_SR 非 0x01 时，CVP 参考路径切换为 LE Audio 下行。若该值配置与实际 LC3 解码采样率不一致，降噪可能把语音误判为噪声（回声抑制异常）。修改采样率配置时应同时核对 LC3 解码器输出配置与 audio_cvp_config.c 的 CONST_REF_SRC 逻辑。

并发与状态机

LE Audio 链路（CIS/BIS）的建立、播放/录音启停均由协议事件驱动，集中在 multi_protocol_event.c 分发。音频播放/录音接口应在协议回调上下文中调用，避免在中断上下文直接操作流对象。
多音源切换（A2DP → Auracast）依赖 net_file_player 的统一播放框架，切换时需按框架规范先停止旧流再启动新流，防止两条等时流同时驱动 DAC。

性能与运维考虑

功耗优化核心是 ACL 复用：RCSP 与 CIS 共用 ACL 是 AC792 SDK 降低 TWS 功耗的核心手段。连接数从"每耳一条 ACL + CIS"降为"一条 ACL 承载 RCSP + 左右耳 CIS"，显著减少广播与扫描开销。启用此特性需保证 get_bt_le_audio_config() 在配对阶段即返回一致值。
等时时序与时延权衡：CIG 参数（cig.c 中的 ISO 间隔、子事件数）决定时延与功耗。间隔越小时延越低，但射频占用与功耗上升。量产调优时建议用 BLE 抓包工具实测 CIS 重传率，目标重传率应低于 1%。
采样率对资源的影响：杰理 JL Unicast 增强（LE_AUDIO_JL_UNICAST_SINK_EN）支持更高采样率（如 48kHz/24bit），会增大 CVP 与 LC3 编解码的 MIPS 与 RAM 占用。低端 Flash/RAM 型号上需评估是否启用 TCFG_LEA_CALL_DL_GLOBAL_SR 非默认路径。
固件体积：六个角色位全部使能会同时编译 cig.c、le_audio_recorder.c、esco_recorder.c、CVP 等模块，代码段显著增大。按产品形态裁剪 TCFG_LE_AUDIO_APP_CONFIG 是控制 Flash 占用最直接的手段。

扩展点

新增 LE Audio 角色：在 TCFG_LE_AUDIO_APP_CONFIG 位掩码中追加角色位后，需同步更新 multi_protocol_common.c/multi_protocol_main.c/multi_protocol_event.c 三处的 #if 条件（它们保持同一组位掩码表达式），并确保音频侧对应 player/recorder 分支已编译。
第三方协议栈接入：通过 THIRD_PARTY_PROTOCOLS_SEL 中的 LE_AUDIO_CIS_RX_EN 位接入第三方 LE Audio 协议栈，CIS 数据收敛到 cig.c 统一管理，音频侧无需改动。这是 SDK 对"自研协议栈/第三方协议栈"双轨支持的关键扩展口。
通话采样率定制：TCFG_LEA_CALL_DL_GLOBAL_SR 与 audio_cvp_config.c 的 CONST_REF_SRC 联动，厂商可按通话质量目标定制下行参考路径。
音频流水线定制：jlstream_pipeline_parse_by_node_name(uuid, "esco_adc") 的按名查找机制允许在流水线中插入自定义节点（如自研 AEC/降噪），LE Audio 通话自动继承，无需修改协议层。

测试与验证建议

仓库未在本页范围内提供独立 LE Audio 单元测试文件，但官方文档（cache/V1.0.0/docs/html/_sources/SDK/earphone/mode/earphone_le_audio/ 下的 RST 源）覆盖了各角色的使用验证流程：

CIS/Unicast：LE_AUDIO_UNICAST_SINK.rst.txt、LE_AUDIO_JL_UNICAST_SINK.rst.txt — 手机配对、CIS 建立、播放/通话切换的验证步骤。
BIS/Auracast：LE_AUDIO_AURACAST_SINK.rst.txt、LE_AUDIO_AURACAST_RECEIVER.rst.txt、LE_AUDIO_AURACAST_ASSISTANT.rst.txt、LE_AUDIO_AURACAST_ECOLOGY.rst.txt — 接收端、辅助端与生态各角色的联调指引。
配套流程图（cache/V1.0.0/docs/html/_images/le_audio_init.png、le_audio_conn_rcsp_adv.png、le_audio_profile.png、le_audio_jl_unicast_clock.png 等）展示了初始化、连接广播、Profile 切换与 JL Unicast 时钟同步的时序，可在文档构建产物中直接查阅。

验证重点建议：① 首次配对加密后再连 CIS；② 断开重连时 Bonding 复用的稳定性；③ RCSP 共用 ACL 下长通话的 CIS 重传率；④ A2DP/LE Audio/Auracast 三音源快速切换的爆音与停顿。