1. WebRTC 音频架构全景：音频引擎架构、音频链路组成、核心模块介绍
做 WebRTC 音频调优，第一件事就是搞清楚音频到底是怎么跑的。很多人一上来就调参数，结果越调越差——说白了，你连数据从哪来、到哪去都没弄明白。
我刚开始接触 WebRTC 时也踩过这个坑。那时候项目上线后总有用户反馈「声音断断续续」，我盯着 NetEQ 参数调了一整天，最后发现是音频采集模块的采样率配置错了。嗯，从那以后我养成了一个习惯：先看架构图，再动手调优。
1.1 音频引擎的整体架构
WebRTC 的音频引擎，官方叫 Audio Engine (AE)。它不是一个单独的模块，而是一整套音频处理管线的集合。我习惯把它分成三层：
- 接口层：暴露给上层应用的 API，比如创建音频轨道、控制音量、设置编解码器。
- 核心处理层：真正的音频处理逻辑都在这里——采集、降噪、回声消除、自动增益控制、编解码、网络抗抖动。
- 硬件抽象层：对接底层音频设备（麦克风、扬声器）和操作系统音频服务。
你想想看，这三层如果有一层出了问题，整个通话质量都会受影响。我在项目中遇到过好几次，明明是硬件驱动的问题，团队却花了两周在核心处理层找原因。
核心观点：音频引擎不是孤立的模块，它依赖设备、网络、操作系统的协同。调优前，先确认每一层都在正常工作。
1.2 音频链路组成：从采集到渲染
一条完整的 WebRTC 音频链路，从麦克风采集声音开始，到扬声器播放出来结束。中间经过的每一个环节，都可能成为质量瓶颈。
我画了一张链路图，你可以对照着看：
链路中的每个环节都有对应的核心模块。我挑几个最重要的给你拆开讲讲。
1.3 核心模块详解
1.3.1 音频采集与渲染
这是最靠近硬件的部分。WebRTC 通过 AudioDeviceModule (ADM) 来管理音频设备。ADM 负责：
- 打开/关闭麦克风和扬声器
- 设置采样率（8kHz、16kHz、32kHz、48kHz）
- 设置声道数（单声道、立体声）
- 处理音频缓冲区大小
我曾经在 Android 设备上遇到过一个问题：某些机型默认的音频缓冲区是 20ms，但 WebRTC 期望的是 10ms。结果就是采集到的音频数据要么溢出要么不足，声音直接变「机器人音」。解决方案是手动适配 ADM 的缓冲区大小。
调优建议：优先确认 ADM 的采样率和缓冲区大小是否与 WebRTC 期望值一致。不一致时，声音质量再好的算法也救不回来。
1.3.2 音频预处理三大件
这部分是 WebRTC 音频质量的「守门员」。三个核心算法：
| 模块 | 全称 | 作用 | 常见问题 |
|---|---|---|---|
| AEC | Acoustic Echo Canceller | 消除扬声器声音回传到麦克风产生的回声 | 回声残留、双讲时声音被吃掉 |
| NS | Noise Suppression | 抑制背景噪声（风扇、键盘、马路声） | 降噪过度导致语音失真 |
| AGC | Automatic Gain Control | 自动调整音量，让声音大小适中且稳定 | 音量忽大忽小、增益过大导致削波 |
这三个模块是串联工作的。顺序一般是：AEC → NS → AGC。为什么是这个顺序？
我个人理解是：回声消除需要原始信号和参考信号做对比，所以放在最前面。降噪放在中间，因为回声消除后残留的噪声需要被处理。AGC 放在最后，因为前面处理完的信号音量可能变了，需要统一调整。
避坑指南：我曾经在项目中把 AGC 放在 AEC 前面，结果 AGC 把回声信号也放大了，AEC 根本消不掉。后来花了三天才定位到这个问题。记住：预处理模块的顺序不要随意改动。
1.3.3 编解码器
WebRTC 默认支持多种音频编解码器。我常用的几个：
| 编解码器 | 采样率 | 比特率 | 适用场景 |
|---|---|---|---|
| Opus | 8kHz - 48kHz | 6kbps - 510kbps | 通用场景，音质最好 |
| PCMU/PCMA | 8kHz | 64kbps | 传统电话系统互通 |
| G.722 | 16kHz | 64kbps | 高清语音 |
| iLBC | 8kHz | 13.33kbps / 15.2kbps | 弱网环境 |
Opus 是目前最推荐的编解码器。它支持可变比特率，网络好时用高码率保证音质，网络差时自动降码率保证连通。我在项目中几乎只用 Opus，除非需要和传统 SIP 电话互通。
1.3.4 NetEQ — 网络抗抖动核心
NetEQ 是 WebRTC 音频引擎里我最佩服的模块。它做两件事：
- 抖动缓冲：把网络到达时间不固定的音频包整理成稳定的播放序列
- 丢包补偿：当音频包丢失时，通过算法预测并填充丢失的声音
NetEQ 的核心是自适应算法。它会根据网络延迟和抖动情况，动态调整缓冲区的深度。网络差时自动加大缓冲，网络好时自动减小缓冲，减少延迟。
我记得有一次线上问题：用户在网络切换时（WiFi 切 4G）出现长达 2 秒的音频卡顿。排查后发现是 NetEQ 的缓冲区重置策略没处理好。后来我们调整了 SetMinimumDelay 和 SetMaximumDelay 的参数，卡顿问题就解决了。
关键参数：NetEQ 的 SetMinimumDelay 和 SetMaximumDelay 直接影响通话延迟和抗抖动能力。默认值通常偏保守，需要根据实际网络环境调优。
1.4 音频引擎的线程模型
WebRTC 音频引擎是多线程的。我简单列一下主要线程：
- 音频采集线程：从麦克风读取音频数据，频率通常 10ms 一次
- 音频渲染线程：向扬声器写入音频数据，频率同样 10ms 一次
- 编码线程：对采集到的音频进行编码
- 解码线程：对接收到的音频进行解码
- NetEQ 线程：管理抖动缓冲和丢包补偿
线程之间的数据传递通过 AudioTransport 接口完成。这里有个容易踩的坑：如果音频采集线程被阻塞超过 10ms，就会导致音频数据断流。我在项目中遇到过因为日志打印太多导致采集线程卡顿的问题，后来把日志改成了异步写入才解决。
1.5 本章小结
WebRTC 音频架构的核心就这些：音频引擎三层结构、从采集到渲染的完整链路、以及 AEC/NS/AGC/编解码器/NetEQ 这几个关键模块。你把这些搞清楚了，后面调优时就知道该从哪里下手。