一、为什么要专门讨论 USB 声卡的延迟

BP-8913 是 USB AUDIO 声卡模块：USB 免驱即插即用，支持 Windows/macOS/Linux，内置 Codec，支持 USB UAC 协议，模拟音频输入输出对外接麦克风和喇叭，工作温度 -20℃~70℃。

这类模块在系统里的角色看起来很简单：把模拟音频变成 USB 数据流。但在实时语音应用中，它常常是延迟的主要贡献者之一，而且这部分延迟往往不出现在任何一份规格书上。

延迟在两类场景下会直接变成问题。第一类是全双工通话：端到端延迟超过约 150ms 后，双方会开始互相打断，超过 300ms 基本无法自然对话。第二类是本地扩音或监听：延迟超过 20ms 就会被说话人感知为回声，超过 50ms 会干扰发音。第三类间接影响是回音消除——AEC 的延迟容忍度是有限的（同家族多数模块标称 100ms），若 USB 链路引入的延迟把参考信号和实际回声的时间差推出这个窗口，AEC 会直接失效。

所以搞清楚这条链路上的延迟从哪来、各占多少，是有实际意义的。

二、把链路拆开：六个环节

一段声音从麦克风到达远端（或回到本机扬声器），要经过以下环节。

1. 模拟前端与 ADC（约 0.5~2ms）

抗混叠滤波器和 Sigma-Delta ADC 的抽取滤波器都会引入群延迟。典型音频 Codec 的 ADC 群延迟在数十个采样周期量级，48kHz 下约 0.5~1.5ms。这一项通常最小，但不是零。

2. USB 传输与帧对齐（1~4ms）

这是 USB 音频的固有开销。USB 2.0 全速设备的帧周期是 1ms，高速设备的微帧是 125μs。UAC 使用等时（isochronous）传输：数据必须打包成整帧，在预定的时隙发出。

这意味着：一段音频采样必须先在设备侧缓冲满一帧（1ms 或 125μs 的量），才能被发出；主机侧接收后也要经过帧边界对齐才能交给上层。加上调度不确定性带来的保守缓冲，实际这一段通常是 1~4ms。

全速（12Mbps）设备用 1ms 帧，高速（480Mbps）设备可以用 125μs 微帧，后者的传输延迟明显更低。这是选型时可以查证的一项。

3. 主机音频栈缓冲（5~50ms，波动最大）

这是整条链路上最大也最不可控的一段。操作系统的音频栈需要缓冲若干个周期以吸收线程调度抖动：

• Windows WASAPI 共享模式：典型 10~30ms；独占模式可低至 3~10ms
• Windows 传统 DirectSound / MME 路径：可达 50~100ms
• macOS CoreAudio：调度较好，典型 5~15ms
• Linux ALSA 直接访问：可配置到几 ms；经 PulseAudio 则通常 20~40ms
• 树莓派等低算力平台：为避免欠载常配置更大缓冲，可达 40ms 以上

同一块 USB 声卡，在不同系统和不同应用框架下，延迟可以相差一个数量级。这一点在选型讨论中经常被忽略——把延迟问题归咎于硬件，实际瓶颈在软件栈配置。

4. 应用层处理（0~30ms）

若上层跑语音编解码（Opus 帧长 20ms 是常见配置）、抖动缓冲、或者软件降噪，各自都会叠加延迟。网络语音应用的抖动缓冲通常是延迟的第二大来源。

5. 回程：DAC 与模拟输出（0.5~2ms）

与 ADC 对称，DAC 的插值滤波器同样有群延迟。

6. 时钟同步引入的额外缓冲

见下一节。

三、时钟域问题：一个容易被低估的环节

USB 声卡的采样时钟与主机的系统时钟是两个独立的时钟源，它们之间必然存在频率偏差（几十到几百 ppm）。若不处理，长时间运行后缓冲区会逐渐积累或耗尽，出现周期性的爆音或断续。

UAC 定义了三种同步模式来处理这个问题，各自的延迟代价不同：

• Asynchronous（异步）：设备自己的晶振为准，通过反馈端点告诉主机应该多发/少发数据。音质最好（时钟不受 USB 抖动影响），但主机侧需要额外的重采样或缓冲调节，延迟略高。
• Adaptive（自适应）：设备根据接收到的数据流速率调整自己的采样时钟（通常用锁相环）。缓冲需求较小，但时钟受 USB 抖动影响，抖动会转化为时钟抖动，劣化 THD+N。
• Synchronous（同步）：设备直接锁到 USB 的 SOF（帧起始）信号。实现简单，但 SOF 的抖动直接进入音频时钟。

对语音应用（16kHz 采样、对 THD 要求不高），三种模式的音质差异不明显，但缓冲策略带来的延迟差异是实际的。对高保真录音，异步模式的优势才显现出来。

还有一个实际现象值得注意：当设备同时用于录音和播放（全双工）时，两个方向如果使用不同的同步机制或不同的时钟域，主机侧必须做重采样对齐，这会进一步增加延迟和处理开销。用同一块声卡同时做输入输出，通常比用两块不同的声卡延迟更低、更稳定。

四、把数字加起来

做一个典型场景的估算：Windows 平台、WASAPI 共享模式、USB 全速设备、上层不做编码。

• ADC：1ms
• USB 上行：2ms
• 主机栈输入缓冲：15ms
• 应用处理：2ms
• 主机栈输出缓冲：15ms
• USB 下行：2ms
• DAC：1ms

合计约 38ms。这个数字对通话是完全可接受的，对本地监听已经偏高（超过 20ms 会被感知），对 AEC 则需要注意：38ms 加上房间混响尾巴（典型办公室 200~400ms 的混响时间，但有效回声能量集中在前 100ms 内），可能已经接近或超出 100ms 的延迟容忍窗口。

如果换成 DirectSound 路径或树莓派的默认 PulseAudio 配置，主机栈缓冲各增加到 40ms，总延迟就到 88ms，加上混响，AEC 大概率失效。

这解释了一个常见现象：同一套硬件在 PC 上通话正常，移植到嵌入式 Linux 平台后回音消不掉。原因不在算法或模块，而在音频栈缓冲配置。

五、BP-8913 在系统里的定位

把 BP-8913 与家族里其它带 USB 的型号对比，可以看出定位差异。

A-59U、A59P、AU-60、AU-48、WX-0813 都带 USB 免驱，但它们同时内置 DSP，在模块内部完成 AEC、降噪、波束等处理，送出的是已处理的语音。BP-8913 的定位是纯粹的 USB Audio 声卡 + Codec，不做语音算法。

这个差异决定了两类完全不同的系统架构：

• 用带 DSP 的模块：算法在模块内部完成，处理延迟固定且短（不经过主机音频栈），AEC 参考信号在模块内部取，延迟可控。主机只负责传输。适合对延迟敏感、主机算力有限的场景。
• 用 BP-8913 + 主机软件算法：模块只做转换，算法跑在主机上。优点是算法可升级、可定制、可以用更复杂的模型；缺点是延迟链路更长，AEC 需要处理主机栈引入的可变延迟，且占用主机 CPU。

后一种架构在 PC 端软件（各类会议软件都自带 AEC）已经成熟的场景下很合理——没必要在硬件里再做一遍。但在嵌入式主机上，通常算力紧张、音频栈配置粗糙，把算法放在模块侧更稳妥。

六、免驱的实际含义与边界

UAC 是 USB-IF 定义的标准类协议，主流操作系统内置驱动，因此"免驱"是协议层面的保证，而不是厂商宣称。它带来的好处包括：不需要为每个平台维护驱动、系统升级不会破坏兼容性、在受限环境（无管理员权限的办公电脑、嵌入式系统）中也能使用。

但免驱也意味着能力被限制在标准定义的范围内：

• 无法通过私有协议下发配置（除非额外实现 HID 或厂商特定接口）
• 采样率、位深、通道数受 UAC 描述符声明的限制
• UAC1 只支持全速（12Mbps），带宽有限；UAC2 支持高速，但 Windows 直到较新版本才原生支持 UAC2

最后一条在跨平台产品上是实际的坑：一个声明 UAC2 的设备，在 macOS 和 Linux 上工作正常，在旧版 Windows 上可能不被识别。多数面向广泛兼容性的产品会选择 UAC1，代价是带宽受限（全速 USB 的等时带宽约 1023 字节/帧，对 48kHz 立体声 24bit 已经接近上限）。对 16kHz 单声道的语音应用，带宽完全不是问题。

七、选型与调试建议

• 明确算法放在哪一侧：主机有成熟软件算法就用纯声卡方案，否则选带 DSP 的模块。
• 实测端到端延迟，不要依赖估算。方法很简单：用另一台设备录制"敲击声原声 + 从系统回放出的声音"，看波形间隔。
• 若要跑 AEC，先确认参考信号与实际播放之间的延迟稳定且在算法窗口内。可变延迟（缓冲区动态调整）比固定大延迟更麻烦。
• 嵌入式 Linux 平台优先直接用 ALSA 而非经过 PulseAudio，缓冲参数按需调小并验证不欠载。
• 全双工尽量使用同一设备的输入输出，避免跨时钟域重采样。

USB 声卡是一类看起来"没什么技术含量"的部件，但它所在的位置恰好是模拟域、数字域、操作系统三者的交界处。链路上的延迟和时钟问题大多产生在这些交界处，而不是在任何单一环节内部。理解这条链路的构成，比比较某一项静态指标更能帮助做出合适的架构决策。