2. 音频基础与实时性指标

TinyML 音频系统与通用深度学习推理最大的差异在于：音频是一个持续到达的时变信号，而非一次性提交的静态数据。麦克风以固定的时间间隔不断产生新的数据，系统必须在数据流中完成采集、缓冲、特征提取和推理，并在下一个数据块到来之前输出结果。如果处理速度跟不上数据到达速度，系统就会丢数据或产生不可接受的延迟。因此，理解音频数字化的基础参数（采样率、位深、帧大小）以及实时性指标（延迟、吞吐量、抖动），是设计任何 TinyML 音频应用（如关键词唤醒、异常声音检测、声学场景分类）的第一步。

上图展示了音频从模拟信号到数字信号、再到帧封装和推理输出的完整链路，以及延迟、吞吐量、抖动、帧大小这四个核心指标在链路中的位置。下面逐一展开讲解。

2.1 音频数字化的三个基础参数

2.1.1 采样率（Sample Rate）

采样率决定了每秒从连续模拟信号中采集多少个离散样本点，单位是 Hz（次/秒）。根据奈奎斯特采样定理，采样率必须大于信号最高频率的两倍才能无失真重建。人耳可听范围约为 20Hz~20kHz，因此 CD 音质采用 44.1kHz 采样率，而语音通信常用 8kHz 或 16kHz。在 TinyML 场景中，16kHz 是语音类任务的事实标准，因为语音能量主要集中在 300Hz~3.4kHz 频段，16kHz 采样率既能覆盖语音有效频带，又能将数据量控制在合理范围。对于声学事件检测（如玻璃破碎、狗叫），可能需要 22.05kHz 或 32kHz 采样率以捕捉更高频的瞬态特征。

采样率的选择直接影响三个维度：频率分辨率、数据量、计算负载。采样率翻倍，每秒需要处理的数据量翻倍，ADC 的功耗也近似翻倍。在电池供电的嵌入式设备上，盲目追求高采样率会显著缩短续航时间。

2.1.2 位深（Bit Depth）

位深表示每个采样点用多少比特来量化幅度，常见有 8bit、16bit、24bit、32bit。位深决定了动态范围和信噪比。每增加 1bit，量化信噪比提升约 6dB。16bit 提供 96dB 的理论动态范围，足以覆盖从耳语到喊叫的语音场景。8bit 仅有 48dB 动态范围，在安静环境下尚可，但背景噪声稍大时就会明显失真。

在 TinyML 中，位深还影响内存带宽和计算精度。16bit 数据在 Cortex-M4 系列（支持单周期 MAC 指令）上处理效率最高。若使用 32bit 浮点，虽然精度高，但多数 MCU 没有 FPU（浮点运算单元），会退化为软件浮点，速度慢 10~50 倍。因此，16bit 定点是 TinyML 音频的主流选择，配合量化感知训练，可以将模型权重和激活也量化为 8bit 或 16bit 整数。

2.1.3 帧大小（Frame Size）

帧大小是每次送入 DSP 或神经网络处理的数据块长度，通常以样本数 N 表示，也可换算为时间长度 T_frame = N / fs。例如，fs=16kHz，帧大小 320 样本，对应 20ms 的音频。帧大小是实时性设计的核心杠杆：

• 帧越小，延迟越低，但频率分辨率越差（DFT 的 bin 宽度 = fs/N），且每次处理的固定开销占比越高。
• 帧越大，频率分辨率越好，计算效率越高（批量效应），但延迟线性增加，且需要更大的 RAM 缓冲。

实际工程中，20ms~40ms 帧长是语音任务的黄金区间。20ms 帧在 16kHz 下为 320 样本，做 512 点 FFT 可得到约 31.25Hz 的频率分辨率，足以区分语音的基频和谐波。对于非语音的瞬态声音（如拍手、碰撞），10ms 帧可能更合适，因为瞬态信号持续时间短，过大的帧会稀释事件特征。

2.2 实时性三大指标：延迟、吞吐量、抖动

2.2.1 延迟（Latency）

延迟是指从声音产生的物理时刻到系统输出响应时刻之间的总时间。在 TinyML 音频系统中，延迟由四部分构成：

1. 采集延迟：ADC 完成一次采样并写入 DMA 缓冲区的时间，通常为微秒级。
2. 缓冲延迟：等待帧填满的时间，等于帧时长。例如 20ms 帧，缓冲延迟就是 20ms。
3. 处理延迟：DSP 特征提取 + 神经网络推理的耗时，取决于算法复杂度和 MCU 主频。
4. 输出延迟：将结果通过 GPIO、UART 或 I2S 输出的时间，通常可忽略。

对于交互式语音应用（如语音唤醒后亮灯），端到端延迟应控制在 100ms 以内，否则用户会感到"迟钝"。对于实时翻译或助听器类应用，延迟要求更严苛，需低于 20ms。注意，缓冲延迟是硬性下限——无论 MCU 多快，20ms 帧至少产生 20ms 延迟，因为必须等够数据才能开始处理。

2.2.2 吞吐量（Throughput）

吞吐量表示系统每秒能处理的帧数或样本数，单位通常为 FPS（帧/秒）或样本/秒。实时性要求吞吐量 ≥ 采样率。例如，16kHz 采样率、20ms 帧（320 样本），则每秒产生 50 帧。系统必须保证每秒至少处理 50 帧，否则缓冲区会持续积压，最终导致丢帧。

在 MCU 上评估吞吐量时，需要测量单帧推理耗时 T_infer。若 T_infer = 15ms，则最大吞吐量 = 1/0.015 ≈ 66 FPS，高于 50 FPS 的实时要求，留有约 32% 的余量。但若 T_infer = 25ms，则最大吞吐量 = 40 FPS，低于 50 FPS，系统无法实时运行。此时需要优化模型（量化、剪枝）或降低帧率（增大 hop）。

2.2.3 抖动（Jitter）

抖动是指帧与帧之间处理时间间隔的波动程度。即使平均吞吐量满足要求，如果某些帧处理耗时特别长（例如发生 cache miss 或中断抢占），就会导致帧间间隔不均匀。抖动对音频应用的影响是音质劣化和控制不稳定：

• 在音频播放场景，抖动会导致声音断续、卡顿。
• 在检测场景，抖动会导致事件时间戳不准确，影响多传感器融合。
• 在控制场景，抖动会导致响应时间不确定，系统行为难以预测。

抖动的来源包括：中断优先级抢占、DMA 传输竞争、动态电压频率调整（DVFS）、cache 行为差异。降低抖动的常用手段：关闭中断嵌套、使用 RTOS 固定优先级调度、将音频处理放在最高优先级任务、避免在音频回调中执行阻塞操作。

2.3 实时性对用户体验的影响

实时性指标不是孤立的工程参数，它们直接转化为用户可感知的体验差异。以智能音箱的唤醒词检测为例：

2.4 案例拆解：16kHz 关键词唤醒系统的实时性设计

假设我们要在 STM32F411（Cortex-M4，100MHz，无 FPU）上实现一个 10 个关键词的唤醒系统，要求端到端延迟 < 100ms，误唤醒率 < 1 次/24 小时。

初始参数设定：

• 采样率 fs = 16kHz，位深 16bit，单声道
• 帧大小 N = 320（20ms），帧移 hop = 160（10ms），即每 10ms 推理一次
• 特征：40 维 MFCC（梅尔频率倒谱系数），FFT 点数 512
• 模型：2 层 CNN + 2 层 Dense，参数量 45K，量化后 8bit

实测数据：

单帧 MFCC 提取耗时： 8.2ms
单帧 CNN 推理耗时：   12.5ms（8bit 量化）
总处理耗时 T_total：  20.7ms
实时帧率要求：       1000/10 = 100 FPS（hop=10ms）
实际可达帧率：       1000/20.7 ≈ 48 FPS

问题分析：实际帧率 48 FPS 远低于要求的 100 FPS，系统无法实时运行。每 10ms 到达一帧新数据，但处理一帧需要 20.7ms，缓冲区会以 10.7ms/帧的速度积压，约 2 秒后溢出丢帧。

优化过程：

1. 第一步：减少推理频率。将 hop 从 160 增大到 320（即每 20ms 推理一次），实时帧率要求降为 50 FPS。此时 48 FPS 仍略低于要求，但接近达标。
2. 第二步：优化 MFCC 实现。将 FFT 从软件浮点改为基-4 定点 FFT，MFCC 耗时从 8.2ms 降至 3.1ms。总耗时变为 15.6ms，实际帧率提升至 64 FPS，超过 50 FPS 要求，余量 28%。
3. 第三步：降低抖动。将 DMA 中断优先级设为最高，关闭音频处理任务中的 printf 调试输出，抖动从 ±3.2ms 降至 ±0.8ms。

结果对比：

复盘经验：本案例的关键教训是——先算吞吐量账，再调模型。如果一开始就盲目压缩模型，可能牺牲精度；而通过调整 hop 和优化 DSP 实现，用更低的成本解决了实时性问题。另外，延迟和吞吐量是矛盾的：增大 hop 降低吞吐量要求，但会增加延迟（因为每帧覆盖的时间变长）。在本案例中，hop 从 10ms 增至 20ms，延迟增加了 10ms，但换来了系统可实时运行，这是值得的权衡。

2.5 常见误区与设计要点

设计 TinyML 音频系统时，建议按以下顺序进行实时性预算分配：

1. 确定任务频带 → 选择采样率和位深
2. 根据交互要求 → 确定最大可接受延迟
3. 由延迟反推帧大小上限（延迟 ≥ 帧时长 + 处理时长）
4. 计算实时帧率要求 → 评估 MCU 算力是否满足
5. 若算力不足 → 优化模型或调整 hop，必要时降低采样率
6. 最后进行抖动测试，确保最坏情况下的帧间隔仍在可接受范围