📚 课程目录第1章 WebRTC音频架构全景

第一章：WebRTC音频架构全景

做嵌入式音频开发这么多年，我见过不少团队一上来就扎进回声消除的算法细节里，结果折腾几个月发现——根本跑不动。为什么？说白了，你连音频引擎的整体架构都没摸清楚，就开始调参数，这跟蒙着眼睛开车没区别。

这一章，我带你把WebRTC音频引擎的骨架搭起来。你搞清楚模块划分、数据流水线、核心交互关系，后面调优才有方向。

WebRTC的音频引擎，我习惯把它拆成三大块：采集与渲染、处理链路、网络适配。每一块都有自己的职责，咱们一个一个看。

关键认知：这三个模块不是独立运行的。ADM把原始音频喂给APM，APM处理完交给编码器，编码器输出经网络送到远端，远端NetEQ负责平滑播放。任何一个环节出问题，整个通话质量都会崩。

我记得有一次，一个客户反馈通话时偶尔出现“咔咔”声。我排查了半天，最后发现是ADM的采集缓冲区配置太小，导致APM拿到的数据帧不完整。嗯，这种问题，光看算法代码是找不到的。

音频数据在WebRTC里是怎么流动的？我画了一张图，你一看就明白。

你想想看，从麦克风采集到扬声器播放，中间经过了多少个处理节点？每个节点都有延迟、有缓冲、有算法开销。我在嵌入式平台上调优时，最常干的事就是拿示波器量每个节点的处理耗时，看哪个环节成了瓶颈。

模块之间的交互，不是简单的函数调用。我总结了几组关键关系，你调试时一定会碰到。

ADM采集到音频数据后，会回调APM的ProcessStream接口。这里有个坑——ADM的采集帧长必须和APM期望的处理帧长一致。APM默认是10ms一帧，如果你的ADM配置了20ms的采集帧长，APM内部会做重采样或缓冲，这就会引入额外延迟。

我曾经踩过的坑：在某款ARM Cortex-M4芯片上，ADM的硬件缓冲区最小只能设到20ms。我强行让APM用10ms帧长处理，结果每次ProcessStream调用都要等ADM攒够两帧数据，回声消除的收敛速度直接翻倍。后来我改了APM的帧长配置，问题才解决。

APM处理完的音频，一路送给编码器发出去；另一路作为参考信号送给NetEQ做播放缓冲。NetEQ内部维护一个抖动缓冲区，根据网络状态动态调整播放速度。

这里有个关键点：回声消除依赖参考信号。如果NetEQ的播放速度和APM的参考信号不同步，回声消除的滤波器就会发散。我建议你在调试时，把NetEQ的播放速率变化率打印出来，看看是不是在合理范围内。

编码器输出的音频包，经过网络到达远端后，NetEQ负责排序、去抖、解码。编码器的码率、帧长直接影响NetEQ的缓冲策略。

编码器	帧长	码率范围	NetEQ缓冲建议
Opus	20ms / 40ms / 60ms	6-510 kbps	60-120ms
iLBC	20ms / 30ms	13.3-15.2 kbps	80-160ms
G.722	10ms	64 kbps	40-80ms

个人经验：在嵌入式平台上，我一般优先用Opus 20ms帧长。帧长太短（10ms）会增加CPU开销，帧长太长（60ms）会加大NetEQ的缓冲延迟。20ms是个不错的平衡点。

WebRTC音频引擎是多线程的。你调试时如果遇到死锁或者数据错乱，八成是线程模型没搞清楚。

我见过最典型的错误：有人在采集线程里直接调APM的ProcessStream，结果APM内部有加锁操作，采集线程被阻塞，导致音频采集丢帧。正确的做法是：采集线程只负责把数据放到环形缓冲区，APM在独立线程里取数据做处理。

调优要点：线程优先级设置很关键。采集线程和播放线程应该设为最高优先级，处理线程次之，网络线程可以低一些。我在某款RTOS上测试过，采集线程优先级设低一级，音频丢帧率从0.1%飙升到3.5%。

WebRTC音频引擎的架构，说白了就是三条线：采集处理线、网络传输线、接收播放线。三条线通过ADM、APM、NetEQ三个核心模块串联起来。你搞清楚了模块划分、数据流水线、交互关系和线程模型，后面调回声消除、调抖动缓冲才有底气。