做音频软件开发10+年，包括语音通信、语音识别、音乐播放等，大部分时间在做语音通信。做语音通信中又大部分时间在做VoIP语音处理。语音通信是全双工的，既要把自己的语音发送出去让对方听到，又要接收对方的语音让自己听到。发送又可叫做上行或者TX，接收又可叫做下行或者RX。之前写了好多关于VoIP语音处理方面的文章，本文想结合框图对相关知识做一个梳理。先综述发送和接收方向的处理，再具体到每个知识点上。讲到某个知识点，如曾经写过相关的文章，就给出链接，如没有写过，等以后写到时再补上链接。由于一些知识点在发送和接收两个方向上是相关的，就放在一起讲。
VoIP语音处理在发送和接收方向上的软件框图如下图1和2：
图1：发送方向处理流程框图
图2：接收方向处理流程框图
在发送方向，从codec芯片采集到语音PCM数据后如有需要首先做重采样（SRC），然后做前处理（回声消除/AEC，噪声抑制/ANS，增益控制/AGC，俗称3A算法）。后面就是做静音检测（VAD），如是语音就编码（ENC），得到码流并通过RTP/UDP发送给对方。如是静音，就生成静音包(SID) 也通过RTP/UDP发送给对方。在弱网情况下为了提高语音质量，就需要前向纠错（FEC）、重传等手段把相应的包发给对方。一些场景下需要把tone音（比如 DTMF tone）发送给对方，先要做tone音检测（tone detection），然后按照SIP协议协商好的方式把tone音发送给对方。在发送RTP包的同时，也需要发送RTCP包来监控RTP包的收发情况等。
在接收方向，先收到对方发来的RTP/RTCP包。对于RTP包，如是正常包或者重传包，直接放进jitter buffer(后面简称JB)，这些包有可能被JB收下，也有可能被JB丢弃（比如包来的太迟或者重复包等）。如是FEC包，先做FEC解码，再把解码后的RTP包放进JB。同样也有可能被JB收下或者丢弃。从JB里取出的如是语音包，就需要做解码（DEC），根据网络状况还可能要做丢包补偿（PLC）、加速、减速、融合等处理。如取出的是静音包（SID），则需要产生舒适噪声（CNG）。如取出的是RFC2833包，就要产生相应的tone音（tone generation）。处理好后还要经过噪声抑制（ANS）/增益控制（AGC）等处理，有可能的话还需要做重采样（SRC）。最后把PCM数据送给codec芯片播放出去。
下面看具体的知识点：
1，语音的采集和播放：主要是从codec芯片采集到语音得到PCM数据和把PCM数据发送给codec芯片播放出来，不同的OS下有不同的方法。曾经写过相关的文章，具体见《音频的采集和播放》。
2，重采样（SRC）：就是把PCM的采样率从一种变成另一种。在音频处理中经常遇到采样率不一样的情况，需要做重采样。曾经写过怎么对开源的重采样算法做评估，从而觉定用哪个，具体见《音频开源代码中重采样算法的评估与选择》。也写过基于sinc方法的重采样的原理和实现，具体见《基于sinc的音频重采样（一）：原理》和《基于sinc的音频重采样（二）：实现》。
3，前后处理的3A算法：包括AEC/ANS/AGC等，他们是保证音质的关键因素之一。AEC是回声消除，曾写过AEC的基本原理和调试经验（算下来我前前后后共四次调试过AEC），具体见《音频处理之回声消除及调试经验》。ANS是噪声抑制，2021年我花了不少时间在ANS上，从学习原理到看懂代码以及自己写算法代码。也写了三个算法的系列，分别是webRTC里的ANS和基于MCRA-OMLSA的ANS以及基于混合模型的ANS，具体见《webRTC中语音降噪模块ANS细节详解(一)》、《 webRTC中语音降噪模块ANS细节详解(二)》 、《webRTC中语音降噪模块ANS细节详解(三)》、《 webRTC中语音降噪模块ANS细节详解(四) 和 《基于MCRA-OMLSA的语音降噪(一)：原理 》 、《基于MCRA-OMLSA的语音降噪(二)：实现》、《基于MCRA-OMLSA的语音降噪(三)：实现(续)》 以及《语音降噪论文“A Hybrid Approach for Speech Enhancement Using MoG Model and Neural Network Phoneme Classifier”的研读 》、《基于混合模型的语音降噪实践 》、《基于混合模型的语音降噪效果提升 》。AGC是自动增益控制，是控制语音信号的增益在预设的合理区间之内，避免忽大忽小。目前这一块还没有相关的文章。
4，静音检测（VAD）和舒适噪声生成（CNG）：VAD会根据预先设定的threshold判断是语音还是静音。如果是语音就要去做编码，如果是静音则不需要编码，仅仅是周期性的（比如200毫秒）发送一个带能量大小的SID包给对方，对方收到这个包后去做CNG产生舒适噪声，让通话者感觉更舒服些。用VAD/CNG主要有两个好处：一是节省了带宽，通常语音通话中一方只占50%左右的讲话时间，其余时间处于静音状态。在静音时发送SID包，SID包比正常语音包小不少，发的频率也低好多，这样就节省了带宽。二是降功耗，在静音期间不需要编解码了，通常编解码的运算load比VAD/CNG高，这样就降低了功耗。目前还没有这方面的文章。
5，编解码（ENC/DEC）：常用的codec有ITU-T的G系列（g.711/g.722/g.726/g.729等）、3GPP的AMR-WB/AMR-NB/EVS以及互联网厂商提出的iLBC/OPUS等。曾在文章《音频的编解码及其优化方法和经验 》中写过基于reference code去优化CPU load。
6，前向纠错（FEC）和重传：在弱网情况下需要保证音质，就得有一些补救措施，FEC和重传就是其中两种。FEC是在发送端编码生成冗余包，在接收端解码从而生成那些丢掉的包。重传是把对方需要的包发给对方。曾在文章《语音通信中提高音质的方法 》讲过这两种方法，当然也讲了其他的提高音质的方法。
7，RTP/RTCP/UDP：这三个都是网络协议，RTP是网络传输协议，RTCP是网络传输控制协议，UDP是数据报协议。在文章《语音传输之RTP/RTCP/UDP及软件实现关键点》里讲了它们的软件实现关键点。
8，tone音：一些场景下会用到tone音，比如DTMF tone，包括tone音检测（tone detection）和tone音生成（tone generation）。文章《谈谈语音通信中的各种tone 》详细的讲了tone音以及发送给对方的三种方式。
9，jitter buffer（JB）：把从网络收到的RTP包放进JB里缓一下，同时把乱序的包排好序等，有利于播放的流畅。文章《音频传输之Jitter Buffer设计与实现 》写了我曾经设计过的一个JB。
10，netEQ：是webRTC里提出的概念，把JB、解码和解码后的PCM处理（加减速播放、丢包补偿（PLC）等）放在一起形成一个模块。也就是接收方框图中画虚线的部分。我曾经写过一个系列详细介绍了netEQ，大家对这个系列的评价还是不错的，具体见《webRTC中音频相关的netEQ（一）：概述 》 《webRTC中音频相关的netEQ（二）：数据结构 》 《webRTC中音频相关的netEQ（三）：存取包和延时计算 》《 webRTC中音频相关的netEQ（四）：控制命令决策 》和 《webRTC中音频相关的netEQ（五）：DSP处理 》。
以上就是VoIP语音处理中的主要知识点。需要说明的是一个VoIP语音处理解决方案中以上模块并不全是必须的，而是根据需求选用的。当然有些是必须的，比如编解码。上面的框图只是把涉及到的知识点列出来，框图画的可能不是十分的准确。有些模块（比如提高音质的一些方法）我没用过，就没画出来。写这篇文章的目的只有一个，就是让大家知道VoIP语音处理的流程和其中有哪些知识点。