7、音频引擎架构：音频采集与渲染、音频编解码器（Opus/iLBC/G.711）、音频处理流水线
各位同学，今天我们来聊聊WebRTC音频引擎。说实话，音频在实时通信里往往是被低估的。大家总觉得视频更重要，画面卡了才叫卡。但做过实际项目的人都知道——音频出问题，通话基本就废了。我见过太多项目，视频流调得漂漂亮亮，一开音频就炸，回声、噪声、丢字，用户直接挂电话。
音频引擎，说白了就是WebRTC的“耳朵”和“嘴巴”。它负责把你说的话采集进来，压缩编码，传到远端，再解码播放出去。听起来简单？嗯，这里面的坑，一个比一个深。
7.1 音频采集与渲染：从麦克风到扬声器的旅程
先讲采集。WebRTC通过getUserMedia()拿到麦克风数据，底层走的是各个平台的音频API。Windows上是WASAPI，macOS/iOS是CoreAudio，Android是AAudio或OpenSL ES，Linux则是ALSA/PulseAudio。
这里有个关键点：采样率。WebRTC内部统一用16kHz或48kHz，但麦克风硬件可能只支持8kHz、44.1kHz。所以引擎内部有个重采样器，负责把硬件采样率转成内部标准。我早期做项目时，没注意这个重采样环节，结果音频一直有轻微的“金属声”，排查了两天才发现是采样率转换精度问题。
- 采集：麦克风 → 音频接口 → 重采样 → 音频缓冲区
- 渲染：音频缓冲区 → 重采样 → 音频接口 → 扬声器
渲染端也一样。解码后的PCM数据要送到扬声器播放。这里有个“缓冲区大小”的取舍。缓冲区越大，抗抖动能力越强，但延迟也越大。WebRTC默认用10ms或20ms的缓冲区，我个人习惯在移动端调到20ms，因为手机CPU调度不稳定，缓冲区太小容易爆音。
7.2 音频编解码器：Opus、iLBC、G.711 三兄弟
WebRTC内置了三种音频编解码器。你想想看，为什么是三个？因为场景不同，需求不同。
| 编解码器 | 比特率 | 采样率 | 复杂度 | 适用场景 |
|---|---|---|---|---|
| Opus | 6–510 kbps | 8–48 kHz | 高 | 通用（默认首选） |
| iLBC | 13.3 / 15.2 kbps | 8 kHz | 中 | 窄带、弱网环境 |
| G.711 | 64 kbps | 8 kHz | 低 | PSTN互通、低延迟 |
Opus 是WebRTC的当家花旦。它支持从窄带到全频带的动态切换，比特率可以实时调整。我在项目中遇到过网络波动，Opus能在几百毫秒内从32kbps降到12kbps，虽然音质下降，但通话不断。这一点，iLBC和G.711都做不到。
iLBC 是Google早年收购来的技术。它的特点是丢包容忍度高。每个包独立编码，丢了一个包不会影响前后帧。我记得有一次在卫星链路上测试，丢包率高达30%，iLBC依然能听清内容，只是有点“机器人声”。
G.711 是最古老的，64kbps固定码率，几乎不压缩。为什么WebRTC还留着它？因为要和传统电话网（PSTN）互通。很多企业客户要求对接老式PBX，G.711是绕不开的。但说实话，64kbps在移动网络下太奢侈了，我一般只在局域网或专线场景下启用它。
7.3 音频处理流水线：从原始声音到干净通话
原始音频是不能直接用的。麦克风采集到的声音里，有环境噪声、有回声、有啸叫。WebRTC的音频处理流水线就是干这个的。它分为几个阶段：
- 回声消除（AEC）：扬声器播放的声音又被麦克风采集回来，形成回声。AEC通过自适应滤波器，把回声信号从采集信号中减去。
- 噪声抑制（NS）：去除背景噪声，比如风扇声、空调声、键盘声。
- 自动增益控制（AGC）：把音量调整到合适范围。说话声音小的人，AGC会放大；声音大的人，AGC会压缩。
- 静音检测（VAD）：判断当前是不是有人在说话。没人说话时，可以停止发送音频包，节省带宽。
这个流水线是串联的。顺序不能乱。AEC必须在最前面，因为回声是最大的干扰源。NS在AEC之后，因为AEC可能会引入新的噪声。AGC放在最后，因为前面处理完的信号电平才稳定。
采集 → AEC → NS → AGC → VAD → 编码 → 发送
我曾经犯过一个错误：把AGC放在AEC前面。结果AGC把回声也放大了，AEC根本消不掉。嗯，从那以后我再也不敢乱调顺序了。
下面这张图展示了音频处理流水线的整体结构：
这里有个细节：AEC需要参考信号。它得知道扬声器正在播放什么，才能从麦克风信号里减去。所以AEC模块有一条从渲染端到采集端的反馈回路。这条回路如果延迟太大，AEC效果会急剧下降。我建议在实现时，保证参考信号延迟不超过10ms。
7.4 实战经验：音频引擎调优要点
最后分享几个我在项目中积累的调优经验：
- 采样率选择：语音通信用16kHz就够了，音乐场景才需要48kHz。采样率越高，CPU消耗越大。
- Opus码率控制：不要固定码率。用WebRTC的
bitrate_priority接口，让引擎根据网络状况自动调整。 - AEC双讲效果：如果双方同时说话，AEC可能会误消。可以调整
aec_delay_agnostic参数，提升双讲场景下的表现。 - 噪声抑制强度：NS太强会损伤语音。我一般把NS设为中等强度（
kModerate），既能去噪又不失真。
好了，音频引擎的核心内容就这些。记住一句话：音频引擎的终极目标，是让用户感觉不到它的存在。好的音频，就是没有存在感的音频。