本地音频概览¶

概述¶

本指南介绍 SF32 器件的本地音频子系统，包括用于麦克风输入、扬声器或线路输出，以及端侧播放和录音的编解码器、DMA 与中间件链路。内容聚焦工程实践中的关键决策：接口选择、缓冲策略、Audio Server 中间件、编解码器选择和功耗。

蓝牙（Bluetooth）音频（A2DP、LE Audio）与本地音频相关，但属于独立主题，详见蓝牙概览。蓝牙概览重点介绍无线传输；本文则说明音频采样数据进入芯片后的处理，包括采集、混音、解码，以及驱动物理音频链路。

本文面向需要将音频功能用于实际产品的工程师，帮助你选择麦克风、编解码器、缓冲方案和功耗策略。目标不只是跑通一次演示，而是在蓝牙、显示、存储和电池预算的约束下，保证音频链路持续可靠地工作。

明确产品的音频需求¶

选择接口或缓冲区大小之前，应先明确产品需求：

• 仅播放、仅录音，还是需要同时播放和录音，即全双工？
• 需要多少个麦克风？使用模拟麦克风（AMIC）还是数字麦克风（DMIC）？
• 本地播放采用什么格式——原始 PCM、MP3、Opus，还是其他编解码格式？
• 是否还需要同时支持蓝牙音频，包括经典蓝牙或 LE Audio？
• 是否需要语音触发或持续监听？相应的功耗预算是多少？
• 扬声器或线路输出有什么驱动要求？音频是否送往外部功放或编解码器？
• 产品对延迟（latency）的容忍度有多大？语音通话和实时监听的要求远比通知提示音严格。

这些答案将决定接口选择（I2S、PDM 或 ADC/DAC）、编解码器配置，以及音频处理链路中哪些部分需要保持唤醒。

SF32 音频信号链路¶

采集和播放使用不同的信号链路。下图展示常见路径；具体可用接口及并发路由能力取决于器件型号、封装、开发板和 SDK 配置。

flowchart TB
    subgraph CAP["采集"]
        direction TB
        A["模拟麦克风"] --> B["AUDCODEC ADC"] --> C["AUDPRC"] --> M["DMA 缓冲区 / 应用"]
        D["PDM 麦克风"] --> E["PDM 转 PCM"] --> M
        F["I2S 输入"] --> C
    end
    subgraph PLAY["播放"]
        direction TB
        N["DMA 缓冲区 / 应用"] --> G["AUDPRC"] --> H["AUDCODEC DAC"] --> J["外部功放"] --> S["扬声器"]
        G --> K["I2S 输出"] --> L["外部编解码器 / 功放"] --> S
    end
    M ~~~ N

AUDCODEC 负责模数和数模转换。AUDPRC 在支持的链路上完成混音、增益和采样率转换等数字处理。PDM 麦克风则由 PDM 模块转换为 PCM，不经过模拟 ADC。I2S 用于连接外部数字音频器件。一个 PDM 接口可通过左右声道选择连接最多两个兼容的麦克风；两个接口最多可连接四个麦克风，但仍须确认引脚是否引出、驱动是否支持。

Audio Server 是管理音频流和会话的软件，并不是串接在麦克风与扬声器之间的物理转换器。应用通常通过其 API 和相应驱动使用音频功能；启动调试时，也可以直接测试驱动或 HAL。应先确定实际的采集和播放路径，再核对时钟、采样格式、DMA 请求及输出端的驱动能力要求。不要默认片内 DAC 无需外部功放就能驱动所选扬声器。

上述路径可参阅 AUDPRC/AUDCODEC 驱动指南和 PDM HAL 指南。

麦克风与数字音频接口¶

AMIC 和 DMIC 表示麦克风类型，PDM 和 I2S 表示数字接口。数字麦克风既可能采用 PDM，也可能采用 I2S。麦克风个数、声道数和接口数量不能混为一谈。

模拟与数字麦克风混合组成阵列时，须确认各链路能够并发工作，且采样时序同步。波束成形还需要合适的麦克风布局、校准和算法，不能仅靠接入多个麦克风实现。

从已验证的音频示例开始¶

在围绕产品需求设计应用行为之前，应先选择并验证最接近的 SiFli-SDK 示例。音频 SDK 示例按照工程任务梳理官方的 PDM、模拟采集、录音/回放、本地音乐、SD 卡、FLAC、Opus 和混音示例，并说明将示例改造成产品前需要重新核对的开发板、引脚复用、存储和配置边界。

选择合适的 SF32 器件¶

各系列的音频能力不同。最终应以具体型号的数据手册为准，以下信息可作为初步选型参考：

选型前，应核对具体型号、封装引脚、引脚复用及并发链路。一个 PDM 接口可连接两个兼容的麦克风；ADC 通道数、麦克风通道数与数字接口数量不能混为一谈。I2S 的收发能力因实例而异：SF32LB58x 的 I2S1 仅支持接收（RX），I2S2 和 I2S3 则支持收发（RX/TX）。使用 I2S2 接收时，还需使能其发送侧作为时钟源。实例限制请参阅 思澈科技（SiFli）I2S HAL 指南；其他选型因素可参阅 SF32 系列概览。

参考来源：DS5201、DS5501, Table 0-1、DS5601、DS5801、SF32LB57x AUDCODEC 寄存器（ADC_CH0/1、DAC_CH0）、SF32LB57x 的 PDM/I2S 外设实例、思澈科技（SiFli）SDK v2.5.1 发布说明（57x 四麦 PDM 配置）、思澈科技（SiFli）SDK PDM 示例（57x 开发板、PDM1、双声道）。

音频会话模板¶

多数产品的音频需求可以归纳为几种常见会话。应选择最接近的模板，并针对实际实现进行验证：

应分别定义每种会话的启动、稳态运行、缓冲区欠载或溢出时的恢复，以及关闭行为。音频问题常隐藏在状态切换过程中，而不是稳定播放循环中。

缓冲区与延迟预算¶

缓冲区可容纳的音频时长应按采样帧计算：一帧包含每个声道各一个采样值。

interleaved frames = buffer bytes / (channels * stored bytes per sample)
planar frames per channel = channel buffer bytes / stored bytes per sample
buffer duration (s) = frames / sample rate (Hz)

在 48 kHz 下，480 帧对应 10 ms。若采用交错存储的立体声，这相当于 960 个采样值；480 个采样值只对应 5 ms。将缓冲区字节数换算为帧数时，应使用实际存储的每采样字节数，包括填充字节。若左右声道分别存储，则按单个声道缓冲区计算帧数，不要将两者的长度相加。

这个结果是缓冲区的音频时长，并不直接等于端到端延迟。乒乓缓冲让 DMA 使用一个区域时，软件可以处理另一个区域；实际延迟取决于队列中等待处理的数据量，以及半传输或整块传输完成时的回调策略，而不只是是否使用两个缓冲区。应统一规划预算并实测采集、处理、传输、播放和任务调度带来的延迟。

播放与录音基础¶

无论是驱动扬声器还是采集麦克风信号，都应遵循以下原则：

• 缓冲区大小——较小的数据块可降低与块处理有关的延迟，但会增加中断和 DMA 开销；较大的数据块可为调度留出更多余量，同时占用更多内存。延迟增加是因为更多音频在处理或播放前排队等待，而不是仅仅分配了更多缓冲区容量。
• DMA 传输——通过硬件定时的 DMA 搬运外设采样数据。软件仍可在内存中按块复制或处理数据；应避免依靠 CPU 轮询或逐采样循环实时服务外设。
• 采样率与格式规划——应预先确定采样率（例如语音使用 16 kHz，音乐使用 44.1/48 kHz）和位深；运行时转换格式会消耗 CPU 和内存。
• 双缓冲——DMA 传输一块区域时，软件填充或处理另一块。必须在该区域再次被使用前完成处理；两个缓冲区本身并不能保证不发生欠载或溢出。

对于与 DMA 共享的可缓存缓冲区，应明确所有权，并遵守 SDK 的缓存行对齐及维护要求。DMA 读取播放数据之前，先将 CPU 写入的数据所在的脏缓存行回写至内存（clean）。DMA 写入采集缓冲区之前，按目标平台缓存策略准备目标区域；传输完成后，CPU 读取之前再使相应区域的缓存失效。只有完成回调确认可以交接后，软件才能修改或复用 DMA 正在使用的区域。受影响的缓存行中不要混放无关数据。

编解码与压缩格式选择¶

应区分硬件音频编解码器（ADC/DAC 转换）和压缩编解码器（如 MP3、Opus）。原始 PCM 不需要压缩解码。对于等效音频信号，有损压缩通常能减少存储体积和读取带宽，但仍须实测解码的 CPU 开销、工作缓冲区和能耗；压缩文件更小，并不保证运行时内存占用也更小。

SDK 提供本地音乐、SD 卡 MP3、Opus、录音及双路 ADC/DAC 示例。双声道示例要求器件和开发板提供对应声道，不代表所有 SF32 都有两个 ADC/DAC。应从支持的示例配置开始，并在实际目标平台上测量解码开销。

本地音频与蓝牙音频¶

即使两条链路需要并发运行，也应在概念上区分：

• 本地音频（本指南）——AUDCODEC/AUDPRC、麦克风、扬声器或线路输出，以及端侧播放和录音。
• 蓝牙音频（蓝牙概览）——经典蓝牙的 A2DP/AVRCP/HFP，或在器件、协议栈和 SDK 支持相应角色时使用 LE Audio 单播/广播。具备 BLE 无线功能并不等于支持 LE Audio。

许多实际产品会让本地音频与蓝牙音频协同工作。例如，采集本地麦克风的声音并通过蓝牙传输，或接收蓝牙音频，再通过 Audio Server 与本地通知提示音混音。两条链路同时工作时，必须明确规划缓冲区所有权和混音行为。

板级音频检查清单¶

固件无法完全掩盖不良的模拟电路设计。在原理图和 PCB 设计阶段，应检查以下项目：

对于同时包含射频和模拟音频的产品，应在蓝牙工作、显示刷新、充电器连接且最终外壳装配完成的条件下验证噪声表现。

音频功耗注意事项¶

分别测量麦克风供电、转换器、数字处理、内存访问与功放的功耗，再测量完整会话。各部分的占比取决于硬件、工作负载，以及监听和播放的占空比。

• 会话之间，按器件和驱动要求的顺序关闭不再使用的音频链路。检查功放静音与关闭控制、时钟、电源及 GPIO 状态，避免爆音、倒灌供电和接口漏电。
• 对于持续监听型语音触发功能，应保留必要的采集链路，并选择所支持的最低功耗处理方案；不能关闭触发功能依赖的链路。触发模型也应尽量轻量。参阅 AI 概览。
• 批处理必须满足延迟预算和缓冲区处理时限。DMA 负责采样数据传输，但完成的块仍须及时处理；减少 CPU 唤醒不能以缓冲区溢出或欠载为代价。
• 协调音频、蓝牙和显示活动的时序。参阅低功耗概览和蓝牙概览：与其他工作负载共存。

音频验证矩阵¶

编解码器、蓝牙、显示、功耗或时钟发生变化后，应重复执行相同的音频测试：

应保留已验证正常的 WAV/PCM 参考文件，以及从评估板采集的正常采样文件。与只依赖主观听感相比，这些参考数据更容易帮助识别回归问题。

音频问题排查¶

常见错误¶

• 通过 CPU 轮询逐个处理外设采样，而不使用硬件定时的 DMA。
• 缓冲区容量不足或管理不当，导致错过 DMA 处理期限；在支持且适用时应使用双缓冲。
• 只按麦克风类型和个数设计，没有核对 PDM/I2S 接口数量、引出的引脚和并发链路。
• 实际产品中本地音频和蓝牙音频需要并发运行，却把二者视为完全独立的系统。
• 忽略 DMA 与 CPU 共享缓冲区的缓存一致性和所有权规则。
• 会话之间仍保持未使用的音频链路工作，或错误关闭持续监听功能依赖的采集链路。
• 在确认解码开销符合功耗和 CPU 预算之前，就确定使用某种压缩格式。

启动调试检查清单¶

• 对照具体器件和开发板，确认麦克风类型与声道数、PDM/I2S 接口数量、引出的引脚，以及支持的并发链路。
• 确定采集和播放的采样率、采样存储位宽、声道布局与缓冲区大小。
• 启动调试所选的 ADC/AUDPRC、PDM 或 I2S 采集链路，以及 DAC 或 I2S 播放链路；先分别测试，再验证全双工。
• 基本硬件链路正常后，通过 Audio Server 和对应驱动集成所支持的会话；保留直接调用 HAL 的测试，便于定位问题。
• 选择音频格式（PCM/MP3/Opus）；需要解码时，实测 CPU 开销、内存占用与能耗是否符合预算。
• 验证 DMA 缓冲区所有权、对齐要求，以及缓存清理和失效操作。
• 如果产品同时使用本地音频和蓝牙音频，验证二者并发运行。
• 测量活动和空闲状态的功耗；验证关闭与重启顺序、接口引脚状态，以及持续监听功能所需的采集链路。

要点¶

• 明确物理链路：模拟音频使用 AUDCODEC，PDM 采集使用 PDM 模块，外部数字音频使用 I2S。通过 Audio Server 和驱动管理所支持的会话，不要将所有路径都理解为同一条编解码器链路。
• 应根据具体器件的能力和产品麦克风布局，选择麦克风类型及 PDM/I2S 链路，不能照搬其他芯片的设计假设。
• 使用由 DMA 按硬件节奏驱动的传输，并配置足够的缓冲深度；在驱动支持且适用时，双缓冲是常见方案，但仍须满足回调处理和缓冲区复用期限。
• 本地音频和蓝牙音频是独立子系统，但经常需要同时运行；必须明确规划混音和缓冲区所有权。
• 音频功耗优化与蓝牙和 AI 类似：缩短活动时间、避免无意义的 CPU 唤醒，并测量真实会话，而不只是稳态播放。

最后更新: 2026-10-21