語(yǔ)音通信是實(shí)時(shí)通信，影響語(yǔ)音質(zhì)量的因素很多，大致可把這些因素分成兩大類：一類是回聲噪聲等周圍環(huán)境因素導(dǎo)致語(yǔ)音質(zhì)量差；另一類是丟包延時(shí)等網(wǎng)絡(luò)環(huán)境因素導(dǎo)致語(yǔ)音質(zhì)量差。這兩類因素由于成因不一樣，解決方法也不一樣。下面就講講用哪些方法來提高語(yǔ)音質(zhì)量。

首先看由于周圍環(huán)境因素導(dǎo)致語(yǔ)音質(zhì)量差的解決方法。這類方法主要是用信號(hào)處理算法來提高音質(zhì)，不同的因素有不同的處理算法，用回聲消除算法把回聲消除掉，用噪聲抑制算法把噪聲抑制住，用自動(dòng)增益控制算法把音量調(diào)整到一個(gè)期望的值。這些都是信號(hào)處理領(lǐng)域比較專業(yè)的算法，好在現(xiàn)在webRTC已經(jīng)開源，也包括這些算法（AEC/ANS/AGC）。我們只要把這些算法用好就有非常不錯(cuò)的效果。這些算法的調(diào)試中AEC相對(duì)復(fù)雜一些，我在前面的文章中（音頻處理之回聲消除及調(diào)試經(jīng)驗(yàn)）專門寫過怎么調(diào)試，有興趣的可以去看一看。ANS/AGC相對(duì)簡(jiǎn)單，先在Linux下做一個(gè)小應(yīng)用程序驗(yàn)證算法的效果，有可能要調(diào)一下參數(shù)，找一個(gè)相對(duì)效果較好的值。驗(yàn)證算法的過程也是熟悉算法怎么使用的過程，對(duì)后面把算法應(yīng)用到方案中是有好處的。

再來看由于網(wǎng)絡(luò)環(huán)境因素導(dǎo)致語(yǔ)音質(zhì)量差的解決方法。網(wǎng)絡(luò)環(huán)境因素主要包括延時(shí)、亂序、丟包、抖動(dòng)等，又有多種方法來提高音質(zhì)，主要有抖動(dòng)緩沖區(qū)（Jitter Buffer）、丟包補(bǔ)償（PLC）、前向糾錯(cuò)（FEC）、重傳等，下面分別一一介紹。

1、Jitter Buffer

Jitter Buffer主要針對(duì)亂序、抖動(dòng)因素，主要功能是把亂序的包排好序，同時(shí)把包緩存一些時(shí)間（幾十毫秒）來消除語(yǔ)音包間的抖動(dòng)使播放的更平滑。我在前面的文章（音頻傳輸之Jitter Buffer設(shè)計(jì)與實(shí)現(xiàn)）中專門寫過Jitter Buffer 的設(shè)計(jì)和實(shí)現(xiàn)，有興趣的可以去看一看。

2、FEC

FEC主要針對(duì)丟包這種因素。FEC屬于信道編碼，想了解原理的朋友可以找相關(guān)文章看，這里就不講了。再說我講也講不好，我掌握信源編碼（語(yǔ)音編碼就是信源編碼的一種），對(duì)信道編碼只是了解。語(yǔ)音上利用FEC來做補(bǔ)償主要是在發(fā)端對(duì)發(fā)出的RTP包（幾個(gè)為一組，稱為原始包）FEC編碼生成冗余包發(fā)給收端，收端收到冗余包后結(jié)合FEC解碼得到原始的RTP包從而把丟掉的RTP包補(bǔ)上。至于生成幾個(gè)冗余包，這取決于收方反饋過來的丟包率。例如原始包5個(gè)為一組，丟包率為30%，經(jīng)過FEC編碼后需要生成兩個(gè)冗余包，把這7個(gè)包都發(fā)給對(duì)方。對(duì)方收到原始包和冗余包的個(gè)數(shù)和只要達(dá)到5個(gè)就可以通過FEC完美復(fù)原出5個(gè)原始包，這5個(gè)原始包中丟掉的就通過這種方式補(bǔ)償出來了。原始RTP包有包頭和payload，冗余包中還要加上一個(gè)FEC頭（在RTP頭和payload中間），F(xiàn)EC頭結(jié)構(gòu)如下：

其中Group first Sequence number是指這一組原始包中第一個(gè)的sequence number，original count是指一組原始包的個(gè)數(shù)，redundant count是指生成的冗余包的個(gè)數(shù)，Redundant index是指第幾個(gè)冗余包。冗余包有自己的payload type 和sequence number，要在SIP的SDP中告訴對(duì)方冗余包的payload type是多少，對(duì)方收到這個(gè)payload type的包后就做冗余包處理。

FEC不依賴與語(yǔ)音包內(nèi)的payload，對(duì)于丟失的包能精確的復(fù)原出來。但是它也有缺點(diǎn)，一是它要累積到指定數(shù)量的包才能精確的復(fù)原，這就增加了時(shí)延；二是它要產(chǎn)生冗余包發(fā)送給對(duì)方，增加了流量。

3、PLC

PLC也主要針對(duì)丟包因素。它本質(zhì)上是一種信號(hào)處理方法，利用前面收到的一個(gè)或者幾個(gè)包來近似的產(chǎn)生出當(dāng)前丟的包。產(chǎn)生補(bǔ)償包的技術(shù)有很多種，比如基音波形復(fù)制（G711 Appendix A PLC用的就是這種技術(shù)）、波形相似疊加技術(shù)（WSOLA）、基音同步疊加（PSOLA）技術(shù)等，這些都很專業(yè)，有興趣可以找相關(guān)的文章看看。對(duì)codec而言，如果支持PLC功能，如G729，就不需要再在外部加PLC功能了，只需要對(duì)codec做相應(yīng)的配置，讓它的PLC功能使能。如果不支持PLC功能，如G711，就需要在外部實(shí)現(xiàn)PLC。

PLC對(duì)小的丟包率（< 15%）有比較好的效果，大的丟包率效果就不好了，尤其是連續(xù)丟包，第一個(gè)丟的包補(bǔ)償效果還不錯(cuò)，越到后面丟的包效果越差。

把Jitter Buffer、FEC、PLC結(jié)合起來就可以得到如下的接收側(cè)針對(duì)網(wǎng)絡(luò)環(huán)境因素的提高音質(zhì)方案：

從網(wǎng)絡(luò)收到的RTP包如是原始包不僅要PUT進(jìn)JB，還要PUT進(jìn)FEC。如是冗余包則只PUT進(jìn)FEC，在FEC中如果一組包中原始包的個(gè)數(shù)加上冗余包的個(gè)數(shù)達(dá)到指定值就開始做FEC解碼得到丟失的原始包，并把那些丟失的原始包PUT進(jìn)JB。在需要的時(shí)候把語(yǔ)音幀從JB中GET出解碼并有可能做PLC。

4、重傳

重傳也主要針對(duì)丟包這種因素，把丟掉的包再重新傳給對(duì)方，一般都是采用按需重傳的方法。我在用重傳的方法時(shí)是這樣做的：接收方把收到的包排好序后放在buffer里，如果收到RTP包頭中的sequence number能被5整除（即模5），就統(tǒng)計(jì)一下這個(gè)包前面未被播放的包有哪些沒收到（即buffer里相應(yīng)位置為空）， 采用比特位的方式記錄下來（當(dāng)前能被5整除的包的前一個(gè)包用比特位0表示，丟包置1，不丟包置0，比特位共16位（short型），所以做多可以看到前16個(gè)包是否有丟包），然后組成一個(gè)控制包（控制包的payload有兩方面信息：當(dāng)前能被5整除的包的sequence number（short型）以及上面組成的16位的比特位）發(fā)給對(duì)方，讓對(duì)方重發(fā)這些包。接收方收到這個(gè)控制包后就能解析出哪些包丟了，然后重傳這些包。在控制包的payload里面也可以把每個(gè)丟了的包的sequence number發(fā)給對(duì)方，這里用比特位主要是減小payload大小，省流量。

在實(shí)際使用中重傳起的效果不大，主要是因?yàn)榻?jīng)常重傳包來的太遲，已經(jīng)錯(cuò)過了播放窗口而只能主動(dòng)丟棄了。它是這些方法中效果最差的一個(gè)。

5、RFC2198

RFC2198是RTP Payload for Redundant Audio Data（用于冗余音頻數(shù)據(jù)的RTP負(fù)載格式），用了它后在當(dāng)前RTP包中不僅可以承載當(dāng)前語(yǔ)音的payload，還可以承載前幾個(gè)包的payload，承載以前包的個(gè)數(shù)越多，在高丟包率的情況下效果越好，但是延時(shí)也就越大，同時(shí)消耗的流量也就越多。相比于FEC，它消耗的流量更多，因?yàn)镕EC用一組RTP包編碼生一個(gè)或多個(gè)成冗余包，而它一個(gè)RTP包就帶一個(gè)或多個(gè)以前包的payload。在有線網(wǎng)絡(luò)或者WIFI下可以用，在蜂窩網(wǎng)絡(luò)下建議慎用。

以上就是我用過的提高音質(zhì)的方法。還有其他方法，我沒實(shí)踐過，就不寫了，寫出來也是紙上談兵。歡迎大家補(bǔ)充其他的方法。