17、WebRTC的音频处理：回声消除（AEC）、噪声抑制（NS）、自动增益控制（AGC）、音频JitterBuffer
音频处理这块，说实话是WebRTC里最容易被低估的部分。很多人觉得视频才难，音频嘛，能出声就行。但我在实际项目中踩过不少坑，发现音频处理才是决定通话质量的关键。你想想看，视频卡顿还能忍，但回声、噪声、声音忽大忽小，用户直接挂电话。
WebRTC的音频引擎（Audio Engine）里，核心模块就四个：AEC、NS、AGC、JitterBuffer。它们各自解决不同的问题，但又紧密配合。我习惯把它们比作一个音频流水线——每个环节出问题，最终听到的声音都会变味。
核心要点：这四个模块不是独立工作的。AEC依赖NS的预处理，AGC需要参考AEC的输出电平，JitterBuffer则要跟编解码器协商延迟。任何一个模块配置不当，整个音频链路都会出问题。
17.1 回声消除（AEC）—— 最让我头疼的模块
回声消除，说白了就是不让对方听到自己的声音从扬声器里传回来。原理上不复杂：麦克风采集的信号里，有一部分是扬声器播放出来的远端声音，AEC的任务就是把这部分去掉。
但实际做起来，坑特别多。我记得有一次做双工通话测试，AEC怎么调都消不干净，最后发现是扬声器的非线性失真导致的。线性AEC只能处理线性回声，遇到非线性失真就抓瞎了。
我的经验：WebRTC的AEC模块默认工作在16kHz采样率。如果你用48kHz，记得先做下采样。另外，AEC的延迟补偿范围默认是100ms，如果系统延迟超过这个值，回声就会漏出来。我曾经在Android设备上遇到过150ms的延迟，调了config.delay_estimator.max_delay才搞定。
AEC的核心算法分两步：
- 线性滤波：用自适应滤波器（通常是NLMS）估计回声路径，减去线性回声。
- 非线性处理：对残余回声做进一步抑制，比如中心削波、舒适噪声注入。
代码层面，WebRTC的AEC配置长这样：
// 初始化AEC
webrtc::AudioProcessing* apm = webrtc::AudioProcessingBuilder().Create();
webrtc::AudioProcessing::Config config;
config.echo_canceller.enabled = true;
config.echo_canceller.mobile_mode = false; // 桌面端用完整模式
apm->ApplyConfig(config);
// 处理音频帧
apm->ProcessStream(audio_frame); // 麦克风输入
apm->ProcessReverseStream(render_frame); // 扬声器参考信号注意：千万别忘了调用ProcessReverseStream！我见过有人只处理了麦克风输入，没给参考信号，结果AEC完全没起作用。另外，参考信号必须和扬声器输出保持同步，延迟抖动太大会导致AEC发散。
17.2 噪声抑制（NS）—— 不是简单的降噪
NS模块负责把背景噪声去掉，比如风扇声、空调声、键盘敲击声。但这里有个度的问题——降噪太狠，语音会失真；降噪不够，噪声又烦人。
WebRTC的NS用的是谱减法，核心思想是：在频域里估计噪声的功率谱，然后从带噪语音中减去。它支持三个等级：低、中、高。我个人习惯默认用中等，除非环境特别嘈杂才开高。
为什么？因为高等级降噪会引入音乐噪声（musical noise），听起来像水烧开的声音，反而更难受。
| NS等级 | 降噪强度 | 适用场景 | 副作用 |
|---|---|---|---|
| 低 | ~6dB | 安静办公室 | 几乎无 |
| 中 | ~12dB | 普通室内 | 轻微语音失真 |
| 高 | ~18dB | 嘈杂街道 | 明显音乐噪声 |
避坑指南：我曾经在车载场景里用过高等级NS，结果语音变得像机器人。后来我改用中等NS，再配合AGC把语音电平提上来，效果反而更好。记住，NS不是越强越好。
17.3 自动增益控制（AGC）—— 让声音大小一致
AGC的作用很简单：把音量自动调整到合适范围。你想想看，有人说话声音大，有人说话声音小，如果没有AGC，用户就得不停调音量。
WebRTC的AGC有两种模式：
- 模拟AGC：调整麦克风的硬件增益。适合有硬件控制接口的场景。
- 数字AGC：在数字域里调整信号幅度。更灵活，但可能引入削波失真。
我建议优先用数字AGC，因为模拟AGC依赖硬件驱动，不同设备表现差异很大。数字AGC只要配置好目标电平（默认-3dBFS）和最大增益（默认30dB），基本不会出大问题。
// AGC配置示例
config.gain_controller1.enabled = true;
config.gain_controller1.mode = webrtc::AudioProcessing::Config::GainController1::kAdaptiveDigital;
config.gain_controller1.target_level_dbfs = -3; // 目标电平
config.gain_controller1.max_gain_db = 30; // 最大增益
config.gain_controller1.compression_gain_db = 9; // 压缩增益
apm->ApplyConfig(config);注意：AGC和AEC有交互。如果AGC在AEC之前做增益调整，可能会放大回声信号，导致AEC负担加重。正确的顺序是：AEC → NS → AGC。WebRTC默认就是这个顺序，别乱改。
17.4 音频JitterBuffer —— 对抗网络抖动的最后防线
JitterBuffer（抖动缓冲）是音频质量的最后一道防线。网络传输中，数据包到达时间不均匀，有的早到，有的晚到，甚至乱序。JitterBuffer的任务就是把这些包排好队，按正确顺序播放。
WebRTC的JitterBuffer是自适应的。它会根据网络抖动情况动态调整缓冲深度。抖动大时，缓冲加深；抖动小时，缓冲变浅。但这里有个权衡：缓冲越深，延迟越大。
我记得有一次做跨国通话测试，网络抖动达到200ms，JitterBuffer自动把缓冲调到了150ms。虽然延迟高了点，但至少声音没断。如果缓冲设得太浅，就会出现声音卡顿、断续。
关键参数：
- 最小延迟：默认20ms。网络好时尽量用这个值。
- 最大延迟：默认100ms。超过这个值，包会被丢弃。
- 延迟调整步长：每次调整的幅度，默认10ms。
JitterBuffer还处理丢包补偿。如果某个包丢了，它会用PLC（丢包隐藏）技术，根据前后包的信息推测出丢失的音频内容。WebRTC的PLC效果还不错，丢包率在5%以内基本听不出来。
// JitterBuffer配置（通过NetEq设置）
webrtc::NetEq::Config neteq_config;
neteq_config.sample_rate_hz = 16000;
neteq_config.enable_fast_accelerate = true; // 快速加速
neteq_config.enable_muted_state = false;
std::unique_ptr<webrtc::NetEq> neteq = webrtc::NetEq::Create(neteq_config);我的建议：如果你的应用场景是实时通话（比如视频会议），JitterBuffer的延迟尽量控制在50ms以内。如果是直播或录播，可以放宽到200ms。另外，开启enable_fast_accelerate可以在网络恢复时快速降低缓冲深度，减少延迟。
17.5 四个模块的协同工作
这四个模块不是各自为战的。我画个简单的流程图你就明白了：
- 麦克风采集音频 → 送入AEC（同时接收扬声器参考信号）
- AEC输出 → 送入NS（去除残留噪声）
- NS输出 → 送入AGC（调整音量到目标电平）
- AGC输出 → 编码 → 网络传输 → 远端JitterBuffer
- JitterBuffer输出 → 解码 → 扬声器播放
你看，每个环节都依赖前一个环节的输出质量。如果AEC没做好，NS和AGC都会受影响。如果JitterBuffer缓冲太深，整体延迟就会变大，影响交互体验。
总结一下：
- AEC：消除回声，依赖参考信号同步
- NS：抑制背景噪声，注意不要过度
- AGC：自动调整音量，注意与AEC的顺序
- JitterBuffer：对抗网络抖动，平衡延迟和流畅度
嗯，这四个模块讲完了。音频处理这块，理论是一回事，实际调优又是另一回事。我建议你在自己的项目里多跑跑测试，用WebRTC自带的audio_processing_test工具验证效果。遇到问题别慌，先看日志，再调参数，一步步来。
公众号:蓝海资料掘金营，微信deep3321