4、WebRTC AEC模块：WebRTC AECM（移动端）与AEC3（桌面端）架构对比、核心参数解析
回声消除这件事，在移动端和桌面端完全是两码事。
我最早接触WebRTC的AEC模块时，以为一套算法通吃所有平台。结果在手机上跑桌面端的AEC3，延迟直接炸了，回声反而越消越大。后来我才明白，Google在WebRTC里其实维护了两套回声消除方案：一套是给移动端省电省资源的AECM，另一套是给桌面端追求极致效果的AEC3。今天咱们就把这两兄弟扒开来看看。
为什么要有两套方案？
说白了，移动端和桌面端的硬件条件差太多了。
桌面端CPU随便跑，内存管够，延迟也低。但手机呢？电池就那么点，CPU还得跟相机、GPU抢资源。你想想看，如果让手机跑桌面级的AEC3，通话还没开始，手机先烫得能煎鸡蛋了。
所以Google做了个取舍：
- AECM（Acoustic Echo Canceller for Mobile）：轻量级，低功耗，适合ARM架构
- AEC3（Acoustic Echo Canceller 3）：全功能，高精度，适合x86架构
我在项目中遇到过最典型的场景：某款低端安卓手机，用AEC3时回声消除效果很好，但通话10分钟后手机降频，声音开始卡顿。换成AECM后，虽然回声抑制深度差了2-3dB，但全程流畅，用户反馈反而更好。嗯，这里要注意：效果不是唯一指标，稳定性才是。
架构对比：AECM vs AEC3
先看一张整体架构对比图，我习惯用这个图来跟团队讲清楚两套方案的区别。
从图上能看出来，AECM的架构更精简，模块之间的耦合度也低。AEC3则复杂得多，多了非线性回声建模和残余回声抑制两个关键模块。
核心差异点详解
1. 自适应滤波器：时域 vs 频域
AECM用的是经典的NLMS（归一化最小均方）算法，在时域做自适应滤波。滤波器长度一般64到128个taps，对应采样率16kHz时，能覆盖4到8毫秒的回声路径。
AEC3则换成了频域自适应滤波（FDAF）。为什么？因为频域做卷积运算更快，而且能更精细地控制每个频点的收敛速度。滤波器长度直接翻倍到256-512 taps，覆盖16-32毫秒的回声路径。
我个人的经验是：如果你的设备回声路径比较短（比如手机听筒），AECM的NLMS完全够用。但如果是桌面扬声器+麦克风这种远场场景，AEC3的频域滤波优势就体现出来了。
2. 延迟估计：粗粒度 vs 精粒度
回声消除最怕什么？怕参考信号和麦克风信号对不齐。
AECM的延迟估计比较粗糙，它只在帧级别做对齐，精度是10ms一级。为什么？因为移动端的音频路径延迟本来就大（蓝牙、DSP处理都会引入延迟），而且不稳定。你想想看，手机从播放到麦克风采集，延迟可能在20ms到100ms之间跳变，这时候追求1ms级的精度反而没意义。
AEC3就不一样了。桌面端的音频路径相对固定，延迟波动小。所以AEC3可以在子帧级别做延迟估计，精度达到1ms甚至更高。配合频域滤波，它能做到非常精准的对齐。
关键参数对比表
| 参数 | AECM | AEC3 |
|---|---|---|
| 滤波器类型 | 时域NLMS | 频域FDAF |
| 滤波器长度 | 64-128 taps | 256-512 taps |
| 延迟估计精度 | 10ms（帧级） | 1ms（子帧级） |
| 双滤波器 | 是（标准+阴影） | 否（单滤波器+后处理） |
| 非线性处理 | NLP（硬削波） | 增益抑制（软处理） |
| 舒适噪声 | 有（简单噪声） | 有（频谱匹配噪声） |
| CPU占用 | ~5% (ARM Cortex-A53) | ~15% (x86 i5) |
| 典型延迟容忍 | ≤100ms | ≤50ms |
3. 双滤波器结构：AECM的独门绝技
AECM有个很有意思的设计——双滤波器。一个叫标准滤波器，一个叫阴影滤波器。
标准滤波器负责稳态的回声路径估计，收敛慢但稳定。阴影滤波器负责快速跟踪回声路径的变化，收敛快但容易发散。两者之间有个切换逻辑：当阴影滤波器的误差明显小于标准滤波器时，就把阴影滤波器的系数复制给标准滤波器。
为什么要这么设计？
我在项目中遇到过这种情况：用户打电话时突然把手机从左手换到右手，回声路径瞬间变了。如果没有双滤波器，标准滤波器需要重新收敛，这期间回声会漏出来。有了阴影滤波器，它能在几十毫秒内跟上变化，然后无缝切换过去。用户根本感觉不到。
AEC3没有双滤波器，它走的是另一条路——精确的延迟估计+频域滤波，配合后处理来消除残余回声。说白了，AEC3相信自己的线性部分足够强，不需要双滤波器这种"备胎"机制。
4. 非线性处理：硬削波 vs 软抑制
这是AECM最容易被吐槽的地方。
AECM的非线性处理（NLP）用的是硬削波。什么意思？就是检测到残留回声时，直接把信号砍掉。这样做的好处是回声抑制得很干净，但坏处也很明显——近端语音也会被误伤，听起来声音断断续续的。
AEC3改用增益抑制，说白了就是根据频点的回声残留量，计算一个平滑的抑制增益。回声大的频点多压一点，回声小的频点少压一点。这样近端语音的损伤小很多，听感更自然。
我建议：如果你的产品对音质要求高（比如会议系统），尽量用AEC3。如果只是语音通话（比如微信语音），AECM的硬削波其实问题不大，因为人耳对语音的连续性没那么敏感。
核心参数解析
不管用AECM还是AEC3，有几个参数你必须搞清楚。
aec_delay_agnostic
这个参数控制是否启用延迟无关模式。默认是false。如果开启，AEC会尝试自动估计和补偿延迟。我建议在移动端开启，因为蓝牙耳机的延迟变化太随机了。
aec_extended_filter
是否启用扩展滤波器。AECM默认关闭，AEC3默认开启。如果你的设备内存够用，建议开启，能多覆盖一些长回声路径。
aec_suppression_level
抑制强度。可选值：kLowSuppression、kModerateSuppression、kHighSuppression。我个人的习惯是：先设成kModerateSuppression，然后根据实际测试结果微调。不要一上来就开最高，否则近端语音损伤会很严重。
aec_comfort_noise
舒适噪声开关。默认开启。关闭后回声消除后的静音段会完全无声，听起来很突兀。除非你有特殊需求，否则别关。
避坑指南
我曾经在一个项目中，把AECM的滤波器长度从128改到256，以为能提升效果。结果CPU占用直接翻倍，而且因为延迟估计跟不上，回声反而变大了。后来我才明白：滤波器长度不是越长越好，它必须和你的延迟估计精度匹配。延迟估计不准，滤波器再长也是白搭。
如何选择？
我总结了一个简单的选择逻辑：
- 手机/平板/嵌入式设备：用AECM。省电、稳定、够用。
- PC/笔记本/会议一体机：用AEC3。效果好、音质高、延迟低。
- 不确定的场景：先跑AECM，如果回声消除效果不达标，再切AEC3。但要注意，AEC3对CPU的要求高不少，得提前评估。
最后说一句：算法选型只是第一步，真正的坑都在集成和调试里。下一节我们会深入AECM的代码实现，看看这些参数在代码里是怎么配置和生效的。
注意
WebRTC的AEC模块在Android上有个坑：不同厂商的音频 HAL 实现差异很大，导致参考信号和麦克风信号的同步关系不稳定。我建议你在集成时，先打印出两路信号的延迟统计，确认延迟在算法容忍范围内，再开始调参数。否则你调了半天，发现是底层音频路径的问题，那就白费功夫了。
公众号:蓝海资料掘金营，微信deep3321