概要

通过音频采集播放偏差问题这篇帖子我们已经知道音频采集播放会有偏差，下面就来分析webrtc是中是通过什么方式来解决的该问题

neteq模块功能

neteq模块中主要有加速（accelerate）、减速（preemptive expand）、丢包补偿（PLC）、融合（merge）和背景噪声生成（BNG），这些都是非常专业的算法。
具体算法不做详细讲解，这里对应音频采集播放的偏差实际是用到了其中的加速、减速、融合的功能。

webrtc中音频的播放架构

webrtc中音频的播放是通过事件驱动，当一帧作用到扬声器上播放完成后触发一个新的可播放事件再去取下一帧，

以win平台的音频播放为例，在core_audio_base_win.cc文件中，会启一个事件监听的线程，当有新的可播放事件时，调用
on_data_callback_(device_frequency);
该接口中会调用到
bool CoreAudioOutput::OnDataCallback(uint64_t device_frequency)
接口中，在该接口内部会调用
audio_render_client_->GetBuffer(num_requested_frames, &audio_data);//获取音频播放缓冲区
fine_audio_buffer_->GetPlayoutData(…)//获取可播放的数据放入音频播放缓冲区中
audio_render_client_->ReleaseBuffer(num_requested_frames, 0);//音频放入完成释放缓冲区进行播放
其中GetPlayoutData接口中主要逻辑是去多个音频接收流的neteq模块中分别获取10ms的pcm数据进行混音得到混音后的数据。具体代码就不走查了，感兴趣的同学可以自行走查该部分代码。

以下是mac平台的播放逻辑，虽然不是事件回调驱动，但是循环检测播放的实现和win回调播放实现类似，就是保证底层有播放空闲时就不停从neteq模块获取音频数据，底层硬件一只有源源不断的音频数据可播，至于网络层是否正常接收到数据底层不管，neteq中维持着pcm数据的缓冲区，依靠对音频数据的拉伸或者压缩或者伪造，来保证缓冲区一只有数据可播，同时尽可能会保证音频有较好的质量

结论

正是由于webrtc中是播放事件驱动音频的获取，当系统负载过高实际播放一帧20ms的音频消耗的时间超过20ms的情况下，pcm数据会堆积在neteq内部，neteq感知的内部pcm数据堆积过多时会通过相关的算法对音频pcm数据进行加速融合，比如将1000个音频采样点压缩为900个采样点而不改变声调，做到不增加延时也不丢pcm数据。当接收端系统正常，而发送端20ms没有采集20ms数据时，随着时间的推移neteq内部的pcm数据将会逐渐变少，neteq感知缓存的pcm数据较少时会对pcm数据进行拉伸，来满足当播放事件驱动来neteq中获取数据时都能有pcm数据返回来达到音频均衡的效果。

以上就是本人对webrtc中neteq模块如何处理音频采集播放偏差问题所做的详细分析，如有谬误欢迎指出。