音频框架与处理节点

AC792N SDK 的音频框架以"音频流程（Audio Flow）"为核心：音频数据从采集/解码源经过一串可编排的处理节点，最终到达输出端。本文档介绍该框架的组成、流程配置文件、处理节点职责与音频流的运行机制。

目的与范围

本文档覆盖 AC792N SDK 中音频框架（Audio Framework）与处理节点（Processing Node）这一子系统，包括：

音频流程配置文件的组织方式（src/音频流程/ 下的 .x6flow 文件）
音频框架的分层架构与音频流（Audio Stream）的运行机制
处理节点的分类与职责（采集、解码、效果、混音、输出）
LE Audio 与 USB Audio 两条典型音频流程
框架的配置、失败模式与性能关注点

范围边界：本文不涉及蓝牙协议栈（LE Audio Profile、RCSP 等）本身的实现细节，也不涉及具体音频算法（EQ、降噪等）的内部 DSP 实现——这些属于其他目录页面的主题。LE Audio 的连接与 Profile 生命周期仅在影响音频流切换时被提及。

说明：AC792N SDK 的音频框架核心以库（lib）形式随 SDK 发布，本仓库可检索到的直接源码工件是音频流程配置文件（.x6flow）以及随包携带的框架文档。凡未经源码验证的推断内容，文中均明确标注。

概述

框架的定位

在 AC792N 这类蓝牙音频 SoC 上，音频通路横跨多种硬件与外设：蓝牙（LE Audio / Classic）、USB、ADC/DAC、I2S、片内编解码器。直接由应用代码拼装这些通路极易出错且难以维护，因此 SDK 采用音频框架 + 处理节点的抽象：

音频流（Audio Stream）：一条有向的数据通路，连接若干处理节点，数据按帧在节点间流动；
处理节点（Processing Node）：流上的一个功能单元，只负责一种职责（采集、解码、效果、输出等）；
音频流程（Audio Flow）：节点编排的"图纸"，决定某条流由哪些节点以什么顺序组成。

流程配置文件（.x6flow）

音频流程以 .x6flow 文件形式随 SDK 工程保存，位于 src/音频流程/ 目录。本仓库可见两条典型流程：

流程文件	用途
LE_Audio.x6flow	蓝牙 LE Audio 通路：接收 LC3 音频流，经解码/效果后输出
USB Audio.x6flow	USB 音频通路：USB 音频数据与板内音频通路互连（含 USB 上行）

SDK 缓存中还保留了这些流程的图形化版本（cache/V1.0.0/config/config/音频流程/），说明流程既可用工具可视化编辑，也会在构建时随工程编译进固件。

关键概念

节点链（Node Chain）：一条音频流上的节点按数据处理顺序串联，前一个节点的输出帧即后一个节点的输入帧；
流调度（Stream Scheduler）：框架按采样率/帧长驱动整条链，使各节点以固定节奏被调用；
流程切换（Flow Switch）：场景变化（如 EDR → LE Audio）时框架重建或重排节点链，SDK 文档图中可见 edr_to_leaudio、le_audio模式切换 等示意。

架构

总体架构

flowchart TD
    subgraph sg_App["应用层"]
        App["应用 / 场景管理"]
    end

    subgraph sg_Fw["音频框架层"]
        FW["音频框架 Audio Framework"]
        NodeMgr["处理节点管理器"]
        Stream["音频流 Audio Stream"]
        Sched["流调度器"]
    end

    subgraph sg_Flow["流程定义 (.x6flow)"]
        LE["LE_Audio.x6flow"]
        USB["USB Audio.x6flow"]
    end

    subgraph sg_Node["处理节点"]
        Capture["采集节点"]
        Decode["解码节点"]
        Effect["效果节点"]
        Mix["混音节点"]
        Output["输出节点"]
    end

    subgraph sg_Hw["硬件/外设层"]
        HW["ADC / DAC / I2S / USB / 蓝牙"]
    end

    App -->|"请求创建/切换音频流"| FW
    FW -->|"加载流程定义"| LE
    FW -->|"加载流程定义"| USB
    FW --> NodeMgr
    FW --> Stream
    Stream --> Sched
    NodeMgr -->|"实例化并串联"| Capture
    NodeMgr --> Decode
    NodeMgr --> Effect
    NodeMgr --> Mix
    NodeMgr --> Output
    Capture -->|"数据帧"| Decode
    Decode --> Effect
    Effect --> Mix
    Mix --> Output
    Capture --> HW
    Output --> HW

架构解读：应用层只与框架交互（创建/切换音频流），不直接触碰硬件。框架根据 .x6flow 流程定义，通过节点管理器实例化节点链，交给音频流与调度器驱动。节点链内的数据帧单向流动，硬件访问被封装在采集/输出节点内部——这正是"框架 + 节点"抽象的核心收益：新增一条音频通路 = 新增一份流程定义，而不是重写驱动代码。

数据流向（按流程类别）

flowchart LR
    subgraph sg_Src["输入源"]
        S1["蓝牙 LE Audio (LC3)"]
        S2["USB 音频输入"]
        S3["本地解码 (文件/内存)"]
    end

    subgraph sg_Proc["处理链"]
        N1["采集/输入节点"]
        N2["解码节点"]
        N3["效果节点"]
        N4["混音节点"]
    end

    subgraph sg_Out["输出端"]
        O1["DAC 输出"]
        O2["I2S 输出"]
        O3["USB 上行"]
    end

    S1 --> N1
    S2 --> N1
    S3 --> N2
    N1 --> N2
    N2 --> N3
    N3 --> N4
    N4 --> O1
    N4 --> O2
    N1 --> O3

LE Audio 流程与 USB Audio 流程共享同一套节点抽象：差异只体现在输入源与节点链的装配方式上。SDK 文档中的 audio_stream_flow.png 即描述了这种"源 → 处理链 → 输出"的流式数据模型。

音频流程定义（.x6flow）

流程文件的角色

.x6flow 是杰理工具链的音频流程工程文件，描述一条音频流所需的节点清单、连接关系与参数。它既是配置工件（构建时随固件发布），也是文档工件（可被工具以图形方式打开）。在 cache/V1.0.0/config/config/音频流程/ 下保留了与 src/音频流程/ 同名的流程文件，说明流程在版本发布时会被固化到 SDK 缓存中，保证固件可复现。

LE Audio 流程（LE_Audio.x6flow）

LE_Audio.x6flow 对应蓝牙 LE Audio 场景：手机/耳机等对端通过 BIS/CIS 通道发送 LC3 编码音频，SoC 侧接收后送入音频框架处理。

SDK 文档图（le_audio_init.png、leaudio音频流程图1.png、leaudio音频流程图2.png）表明该流程的关键环节包括：

LE Audio 协议栈初始化与 Profile 使能；
ACL 连接建立（RCSP 广播引导配对，见 le_audio_acl_conn_rcsp_adv.png）；
音频流建立：LC3 解码节点挂入节点链；
输出：DAC/I2S 输出节点。

USB Audio 流程（USB Audio.x6flow）

USB Audio.x6flow 对应 USB 声卡/耳机场景：USB Host 以等时传输（Isochronous）下发音频数据，SoC 作为 USB Audio Device 接收并播放；同时支持将板内音频（如麦克风采集）通过 USB 上行回传。

该流程在节点装配上的特点是双向性：下行（Host → DAC）与上行（采集 → USB）共用节点抽象但方向相反，框架需要保证两条方向的帧同步与采样率匹配。

流程与固件构建的关系

流程文件位于 src/ 工程目录内，属于应用层可配置部分（而非 lib 内部实现），这意味着：

客户/方案商可以在不改动 SDK 库的前提下，通过调整流程文件改变音频通路拓扑；
同一固件可同时编译进多条流程（LE Audio、USB Audio 等），运行时按场景切换。

说明：.x6flow 为工具链私有格式，其内部字段语义需在杰理音频流程编辑工具中查看；本次探索预算内未读取文件正文，以上为基于文件布局与文档图的结构性描述。

处理节点详解

处理节点是音频框架的基本执行单元。一条音频流上的每个节点只承担一种职责，并通过统一的帧接口与相邻节点交换数据。以下节点类别是框架层的主要抽象（类别划分依据为框架文档图与流程文件布局；各节点在 SDK 中以库形式提供，具体 API 签名未在本仓库源码中暴露）：

节点类别	职责	典型挂载位置
采集/输入节点	从 ADC、USB、蓝牙等源读取音频帧	节点链头部
解码节点	将编码流（LC3/AAC/SBC 等）解码为 PCM	采集节点之后
效果节点	施加 EQ、音效、降噪等处理	解码之后、输出之前
混音节点	合并多路 PCM（如提示音叠加音乐）	效果之后
输出节点	将 PCM 送往 DAC/I2S/USB 上行	节点链尾部

节点的统一接口（框架级约定）

框架对节点的约定是输入输出皆为连续 PCM 帧流，节点不感知上游的物理来源。由此获得两个设计收益：

可组合性：任意采集源 + 任意处理链 + 任意输出端可以自由装配，只要采样率/位宽/声道数匹配；
可测试性：处理逻辑与硬件解耦，效果节点可在脱离硬件的情况下用文件流验证。

Hi-Res 音频与采样率

SDK 文档包含 hi_res_audio_definition.png，说明框架支持 Hi-Res 音频定义（高采样率/高位深）。这意味着节点链需要支持：

多采样率配置（如 48 kHz / 96 kHz / 192 kHz）；
采样率转换（SRC）节点或在输出节点内完成重采样；
高采样率下节点调度周期缩短，对 CPU 负载与延迟预算更敏感。

核心流程：音频流生命周期

音频流从创建到销毁的完整生命周期如下：

sequenceDiagram
    participant App as 应用/场景管理
    participant FW as 音频框架
    participant NM as 节点管理器
    participant N as 处理节点链
    participant HW as 硬件/外设

    App->>FW: 请求创建音频流（指定流程，如 LE Audio）
    FW->>NM: 解析流程定义，实例化节点清单
    NM->>N: 按序初始化各节点
    N->>HW: 打开硬件通路（DAC/I2S/编解码器）
    FW->>FW: 启动流调度器（按采样率/帧长驱动）
    loop 每帧周期
        N->>N: 采集/解码节点产出 PCM 帧
        N->>N: 效果/混音节点处理
        N->>HW: 输出节点写入 DAC/I2S
    end
    App->>FW: 停止音频流
    FW->>NM: 停止调度并释放节点链
    NM->>N: 去初始化，关闭硬件通路

关键设计点：

创建阶段：框架把流程定义（节点清单）解析为可执行的对象图。流程文件与运行时的关系类似"蓝图 → 实例"，同一流程可同时实例化多条流（如播放与录音并行）；
运行阶段：调度器以固定帧周期驱动整条链，节点间通过帧队列/回调衔接，避免每条流各自开定时器带来的抖动；
销毁阶段：逆序释放，保证硬件通路先停后关，避免 DAC 输出毛刺。

音频流程切换

AC792N 支持多种音频通路并存，场景变化时需要在流程之间切换。SDK 文档图（edr_to_leaudio.png、le_audio模式切换.png）给出了两类典型切换：

EDR（Classic）→ LE Audio：从经典蓝牙 A2DP 通路切到 LE Audio 通路。切换前需完成 LE Audio Profile 初始化（le_audio_profile.png）与连接建立，音频框架侧则重建节点链（解码节点由 A2DP 解码器换成 LC3 解码器）；
模式退出：LE Audio Profile 退出时（le_audio_profile_exit.png），框架回收节点链，回退到默认通路或进入广播待连接状态（le_audio_not_conn_rcsp_adv_not_en.png）。

切换的原子性是框架层的核心关注点：切换过程中不允许出现"新旧两条流同时驱动同一硬件"的窗口，否则会产生爆音或硬件冲突。典型做法是先建新链、停旧链、再原子切换调度目标。

配置选项

音频框架的配置主要沉淀在流程文件与构建缓存中。以下配置项按文件布局与文档证据整理：

配置项	类型	默认/取值	说明
流程文件选择	文件	`LE_Audio.x6flow` / `USB Audio.x6flow`	决定节点链拓扑；可在 `src/音频流程/` 下按方案增删
采样率/位深	数值	随流程定义（支持 Hi-Res）	影响节点链 SRC 配置与调度周期
音频配置存储	内存区	RAM（见 audio_config_ram.png）	框架运行时配置（如音量、EQ 参数）保存在 RAM，可动态更新
流程导出开关	构建选项	见 audio_flow_export_enable.png	控制流程是否导出到固件/调试输出

注意：.x6flow 内部的精确参数键（如节点参数、缓冲区大小）需在杰理音频流程编辑工具中查看，本次未能在源码检索中验证其字段名，故上表仅列出已验证存在或文档明确提及的配置面。

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

典型失败模式

连接失败回退：LE Audio ACL 连接未建立/失败时，框架不启用 LE Audio 节点链，保持广播待连接或回退 EDR 通路（对应文档图 le_audio_not_conn_rcsp_adv_not_en）；
流程切换竞争：切换期间若新链尚未就绪而旧链已停止，会造成短暂无声；框架须保证切换串行化，避免并发触发两次切换；
采样率不匹配：USB Audio 的 Host 采样率与板内 DAC 采样率不一致时，若无 SRC 节点兜底，会出现音调异常或帧溢出/欠载。

并发与一致性

音频回调运行在实时上下文中（中断/高优先级任务），而配置更新（音量、EQ）来自应用上下文，二者天然并发。框架需要：

节点参数更新采用"双缓冲/延迟生效"语义，避免回调中读到半更新的参数；
流程切换与节点增删必须在调度器静止（或加锁）状态下进行，防止链表遍历中被修改。

边界情况

空流/无数据源：采集节点无帧可读时，输出节点应输出静音帧而非停顿，防止 DAC 挂起；
高采样率下帧长变小：调度开销占比上升，需要按帧批量处理以摊薄开销。

性能与运维

延迟预算：LE Audio 对端到端延迟敏感，文档含 leaudio_latency.png 专图，说明延迟是 LE Audio 流程的显式设计指标。延迟由蓝牙链路缓冲、节点链缓冲、DAC 缓冲三级叠加，框架需平衡缓冲深度与欠载风险；
CPU 负载：效果节点（EQ/音效）与 LC3 解码是主要算力消耗点；节点链允许按场景裁剪（如省电模式去掉效果节点）；
调试与导出：通过流程导出开关（audio_flow_export_enable）可将运行时流程拓扑导出，便于现场核对实际生效的节点链与配置。

扩展点

框架的扩展性体现在三个层面：

新增流程：在 src/音频流程/ 增加 .x6flow 文件（如新的外设音频通路），即可复用现有节点库装配新通路；
新增节点：符合框架节点接口（PCM 帧输入/输出）的自定义处理单元可插入现有链——SDK 以库形式提供节点注册机制，具体注册接口需查阅 SDK 库头文件（本次未在仓库源码中验证其签名）；
切换策略：场景管理器决定何时触发流程切换（EDR ↔ LE Audio ↔ USB），该策略属于应用层，可在不改动框架的前提下定制。

测试

SDK 文档图（le_audio_init、le_audio_profile、leaudio音频流程图1/2）本身即框架作者提供的流程级"测试用例/时序参考"，可用于验证初始化、连接、播放各阶段行为；
框架的"节点链 + 流程定义"结构天然支持组件级验证：对单个效果节点可用固定 PCM 输入比对输出，无需整机。

本次探索预算内未定位到仓库中的自动化测试代码；若后续版本包含测试目录，可在对应页面补充。

使用示例

音频流程文件布局（已从仓库验证）

音频框架的可见源码工件是流程配置文件，其组织方式如下（来自仓库文件清单）：

src/音频流程/
├── LE_Audio.x6flow      # LE Audio 音频通路流程
└── USB Audio.x6flow     # USB 音频通路流程

cache/V1.0.0/config/config/音频流程/   # 发布缓存中的同源流程文件

说明：.x6flow 为工具链私有格式，需在杰理音频流程编辑工具中打开编辑；本页不伪造其内部内容。

运行时流程示意（框架概念示例）

本仓库以库形式发布音频框架，未提供可直接引用的框架调用源码。以下为框架概念层面的调用顺序示意，并非从本仓库源码提取，仅供参考理解：

应用侧（概念）：
  1. audio_fw_init()               # 初始化音频框架（含节点管理器）
  2. audio_fw_load_flow("LE_Audio") # 按流程定义实例化节点链
  3. audio_fw_stream_start()       # 启动流调度
  4. audio_fw_stream_stop() / audio_fw_exit()  # 停止并回收

现状说明：在本次源码探索预算内，未能在仓库中检索到音频框架的 C 源码或头文件（框架随 SDK 以 lib 形式提供）。上述示例仅用于传达框架的调用语义，具体 API 名称与签名以 SDK 库头文件为准，请勿将示例中的函数名当作已验证接口使用。

API 参考

现状说明：音频框架 API（流创建、节点注册、流程加载、调度启停等）以库形式提供，其签名未在本仓库源码中验证，因此本页不列出具体方法签名，避免误导。如需精确签名，请查阅 SDK 发行包中的库头文件，或参考框架文档图（如 audio_stream_flow.png、le_audio_init.png）对应的初始化时序。

框架级接口职责（概念层）：

接口职责	说明
框架初始化/退出	初始化节点管理器与调度器；退出时回收全部流
流程加载	读取 `.x6flow` 定义并实例化节点链
流启停	启动/停止调度器对节点链的驱动
节点参数更新	运行时修改节点参数（音量、EQ），要求并发安全
流程切换	在两条节点链之间原子切换