qq_44660239的博客

以上就是两种混音方式的对比，综合来看在端侧进行混音效果应该会更好一些，因为腾讯会议以及ZOOM都是采用端侧混音的方式进行的实现。

从以上分析中可以看出，RTP场景下要不断发送SR报文校准音频采集的偏差，来让接收端能实现正常的音视频同步。

在RTC场景下，音频时间戳通常按照音频的帧数固定递增，基于采样率和帧长度计算时间戳的递增间隔。这种设置方式确保了音频数据的稳定性和实时性。简而言之，音频时间戳是按照固定的帧间隔递增的，例如每20ms增加960（在48kHz时间基下），而不是基于实际采集时间。

在实时通信（RTC）场景下，视频时间戳的设置通常是基于采集时间（系统时间），而不是按照帧率固定递增。这种设置方式能够：准确反映每一帧的实际采集时间，确保音视频同步。适应帧率波动和网络抖动，支持接收端更好的去抖。满足RTC对实时性和低延迟的高要求。如果采用固定递增的时间戳设置方式，可能会因为帧率波动或网络抖动导致时间戳偏差，从而影响音视频的同步和延迟控制。因此，在RTC场景下，基于采集时间的时间戳是更合适的选择。

正是由于webrtc中是播放事件驱动音频的获取，当系统负载过高实际播放一帧20ms的音频消耗的时间超过20ms的情况下，pcm数据会堆积在neteq内部，neteq感知的内部pcm数据堆积过多时会通过相关的算法对音频pcm数据进行加速融合，比如将1000个音频采样点压缩为900个采样点而不改变声调，做到不增加延时也不丢pcm数据。以win平台的音频播放为例，在core_audio_base_win.cc文件中，会启一个事件监听的线程，当有新的可播放事件时，调用。)//获取可播放的数据放入音频播放缓冲区中。

提示：这里可以添加总结从以上实验可以看出，音频的采集和播放耗时都和理论值有所偏差，如果不对这些偏差做相关处理发送端直接发送，接收端直接解码播发，将会使音频效果出现问题。比如，发送端音频就是20ms采集一帧进行发送，而接收端播放音频每20.1ms才能播完一帧，那么随着时间的推移，接收端势必会出现接收数据堆积越来越多的问题，那么接收端的播放延时会越来越大，如果接收端堆积数据过的时进行丢弃那么又会造成音频数据包的丢失导致音频出现卡顿的现场。

上图横轴为每一帧的时间戳，纵轴为每帧完整时进行处理通过系统接口获取的当前时间now_ms(也可以理解为一帧在接收端接收的时间),其中绿色的点为每帧实际的时间戳对应的实际接收时间now_ms,最下方黑色虚线为结合所有帧的时间戳和now_ms经过卡尔曼滤波之后拟合出来的一个直线，红色点为最后这一帧根据其自身时间戳在拟合的线性关系上预测出的点，其纵轴对应的为预测出的本地时间Localtime,红色点上方的绿色点为实际该帧在接端接收的时间，灰色的虚线为每帧的实际解码的时间点，最上方黑色虚线为每帧渲染的时间点。