音频的传输链路与延迟优化点

麦克风->系统采集模块->APP采集模块->3A、混响等音效->混音->音频编码->RTC网络发送->

MediaServer->RTC网络接收->音频jitter buffer->音频解码->音频的后处理(均衡)->APP播放模块->x系统播放模块->扬声器/耳机。

整个链路如上；

采播延迟：

音频的『采播延迟』不同机型的差异比较大，iOS效果比较好，采集+播放大约在20-30ms.

Android好的机型在30ms，差的机型可以达到300ms.

优化手段：通过AAudio等方式对延迟进行优化。

目标延迟：iOS:20-30 Android: 部分机型30-70ms

3A延迟

音效需要分开来看，一般混响类音效不会引入延迟，但是变声类音效会引入延迟。

优化手段：佩戴有线耳机，可以关闭3A，减少30ms延迟。

对外外放场景，可以对30ms的3A算法进行优化到10ms。

限制不开启音效，或者只开启不引入延迟的混响音效。

目标延迟：耳机 0ms。 外放 10ms。

RTC编码

RTC的音频编码帧长一般是20ms.

优化手段：需要将编码帧长变为10ms, 支持全链路10ms帧长，减少10ms延迟。

RTC网络延迟 

一般就是RTT/2, 通过多部署边缘服务器来做到尽可能离得用户近一点，通过关闭Pacer等网络传输策略的优化。

网络较好的情况下，延迟约为5-10ms。

音频jitter buffer延迟

引入延迟最多的地方，是RTC区别于直播，能做到百毫秒延迟的原因，主要是根据网络状态动态调整jitter buffer的大小。

引入延迟的目的是为了抗抖动，延迟越高，抗抖动能力越强，卡断越少。

相比于延迟，卡顿对于用户体验影响更大，一般会引入100-1000ms的延迟，大部分场景在300ms一下。

优化手段：

减少jitter buffer的大小，结合其他手段来减少卡顿（FEC、NACK、主动重传、快速下降、10ms编码帧长）来防止频繁的卡断。

最小维持在30-40ms，才能保证MOS打分。

理想情况下的总延迟(iOS)：

30(采播延迟) + 0（3A+音效bypass）+ 5（编码）+5（上行网络传输）+5（下行网络传输）+35（jitter buffer）+0(后处理算法bypass) = 80ms。