一、概述

音频的QOS可以分：音频前处理3A算法、NetEQ两大类。

二、音频前处理3A算法

1）AEC

AEC (Acoustic Echo Cancellation) 回声消除算法

默认IOS和ANDROID、windows系统都使用内置的AEC算法。若要使用webrtc的AEC算法，需要单独配置。配置过程请参见

WebRtcVoiceEngine::Init
->WebRtcVoiceEngine::ApplyOptions

AEC算法原理分析，请参见《webrtc AEC算法原理分析》

2）ANS

ANS (Automatic Noise Suppression)自动降噪。

该算法适用于多方会议入会，若没有噪声抑制，每个与会方都自带背景噪音，混音叠加会导致会议背景音嘈杂。
 

3）AGC

AGC (Automatic Gain Control) 自动增益控制

自动调麦克风的收音量，使与会者收到一定的音量水平，不会因发言者与麦克风的距离改变时，声音有忽大忽小声的缺点。

三、NetEQ

1）实现框架图

2）函数调用关系

NetEqImpl::InsertPacketInternal函数与NetEqImpl::GetAudioInternal函数之间通过packet_buffer_共享队列传输音频报文数据。

在NetEqImpl::InsertPacketInternal函数中入队音频报文、在NetEqImpl::ExtractPackets函数中出队报文。

NetEqImpl::GetAudio
->NetEqImpl::GetAudioInternal     
->NetEqImpl::GetDecision
->NetEqImpl::ExtractPackets
 

1）抗丢包方法

1、NACK：丢包重传协议。

NACK重传协议主要是不仅考虑丢包重传，还需要考虑与JitterBuffer配合的情况，因为JitterBuffer会有一些变速操作，不是所有的报文都会重传，NACK会定时在解码前更新了一下需要重传报文的序列。详情请参考：

webrtc音频QOS方法四（音频接收端NACK流程实现）_CrystalShaw的博客-CSDN博客一、概述发送端的音视频NACK实现没有差异，可以公用一套rtp_packet_history代码，但是在接收端，音视频NACK实现细节是不一样的。视频接收端NACK实现函数是NackModule2，音频接收端NACK实现函数是NackTracker。音视频NACK实现差异主要有两点：视频NACK满足一定条件会进行IDR帧请求：视频模块会配置nack_list的最大长度为kMaxNackPackets，即本次发送的nack包至多可以对kMaxNackPackets个丢失的包进行重传请求。如果丢https://blog.csdn.net/CrystalShaw/article/details/123238055

2、FEC：冗余协议。webrtc目前使用的是opus带内FEC冗余编码，详情请参考：

webrtc音频QOS方法二（opus编码器自适应网络参数调整功能）_CrystalShaw的博客-CSDN博客一、opus函数调用接口二、自适应网络调整参数介绍1、WebRtcOpus_SetBitRate Opus支持码率从6 kbit/s到510 kbit/s的切换功能，以适应这种网络状态。以20ms单帧数据编码为例，下面是各种配置的Opus的比特率最佳点。2、WebRtcOpus_SetPacketLossRate 动态配置丢包率，是为了动态调整opus FEC的冗余度。opus编码器自带inband FEC冗余算法，增强抗丢包能力。大概使用的是...https://blog.csdn.net/CrystalShaw/article/details/106940151

3、交织编码。

NetEqImpl::InsertPacketInternal函数主要实现解析FEC冗余报文，检测丢包申请NACK重传功能。

2）抗抖动方法

• JitterBuff

抗网络抖动由三个模块共同完成：网络延时统计算法、缓冲BUF延迟统计算法、控制命令决策判定。

webrtc会根据网络延时(DelayManager)和缓冲BUF已经缓存数据长度(BufferLevelFilter)以及上一帧的处理方式等，决定给解码器发什么信号处理命令。

DelayManager、BufferLevelFilter算法实现，请参见《NetEQ之音频网络延时DelayManager计算》、《NetEQ之音频缓存延时BufferLevelFilter计算》。

实现代码：

->NetEqImpl::GetAudioInternal
->NetEqImpl::GetDecision
->DecisionLogic::GetDecision   
--->DecisionLogic::FilterBufferLevel----计算未被播放，放在缓冲区（包括packet_buffer_、sync_buffer_）音频数据，可播放时长
--->DecisionLogicNormal::GetDecisionSpecialized
->DecisionLogicNormal::ExpectedPacketAvailable
->DelayManager::BufferLimits-----------计算网络延时

• 音频平滑处理方法

音频解码信号处理命令有主要有五种：kNormal(正常播放)、kAccelerate(加速播放)、kExpand(减速播放)、kAlternativePlc(丢包补偿)、kMerge(融合)，原理如下：

虽然前面有抗抖动方法尽量保证音频质量，但是在一些特定网络，音频渲染时还是可能出现音频数据堆积、断流现象。若不进行特殊处理，音频时快时慢，用户体验较差。这里webrtc引入变速不变调算法进行平滑处理：

1、累积数据过多时，通过该算法，不影响用户体验情况下，减少这些数据播放时长。

2、音频播放BUF数据不足时，通过该算法，增加这些数据播放时长。让用户感知不到音频数据的波动。

在弱网丢包率比较高情况下，数据相对长时间丢失，变速不变调算法也无法满足实际应用，webrtc又引入了丢包补偿、音频融合算法，衔接和平滑音频质量。

1、丢包补偿算法原理是根据前一帧的解码信息，利用基音同步重复的方法近似替代当前的丢失帧，以达到丢包补偿。 

2、融合算法是当上一次播放的帧与当前解码的帧不连续的情况下，进行衔接和平滑处理。让两个数据包一部分播放时间重叠，使过度更自然。

处理函数NetEqImpl::GetAudioInternal

参考

浅谈 WebRTC NetEQ - 简书

webRTC中音频相关的netEQ（一）：概述 - davidtym - 博客园

http://sxjs.cnjournals.cn/ch/reader/create_pdf.aspx?file_no=20100512&flag=1&journal_id=sxjs&year_id=2010