時(shí)延是語音通信中的一個(gè)重要指標(biāo)，當(dāng)端到端(end2end)的時(shí)延（即one-way-delay,單向時(shí)延）低于150Ms時(shí)人感覺不到，當(dāng)端到端的時(shí)延超過150Ms且小于450Ms時(shí)人能感受到但能忍受不影響通話交流，當(dāng)端到端的時(shí)延大于1000Ms時(shí)嚴(yán)重影響通話交流，用戶體驗(yàn)很差。同時(shí)時(shí)延也是語音方案過認(rèn)證的必選項(xiàng)，超過了規(guī)定值這個(gè)方案是過不了認(rèn)證的。今天我們就講講時(shí)延是怎么產(chǎn)生的以及怎么樣在通信終端上減小時(shí)延。

1、時(shí)延產(chǎn)生

下圖是語音從采集到播放的傳輸過程。

從上圖看出，傳輸過程包括三部分，一是從發(fā)送端采集到語音數(shù)據(jù)處理后發(fā)送到網(wǎng)絡(luò)設(shè)備，二是網(wǎng)絡(luò)設(shè)備之間傳送，三是從網(wǎng)絡(luò)設(shè)備發(fā)送給接收端并播放出來。每個(gè)過程都會(huì)產(chǎn)生時(shí)延，總體可以分為三類。一是通信終端上引入的時(shí)延，這時(shí)本文要講的重點(diǎn)，后面具體講。二是通信終端和網(wǎng)絡(luò)設(shè)備之間的時(shí)延，包括采集終端到網(wǎng)絡(luò)設(shè)備的延時(shí)和網(wǎng)絡(luò)設(shè)備到播放設(shè)備的延時(shí)。三是網(wǎng)絡(luò)設(shè)備之間的時(shí)延。二和三屬于網(wǎng)絡(luò)設(shè)備引入的延時(shí)，本文不討論。

現(xiàn)在我們具體看通信終端上引入的時(shí)延，它在發(fā)送端（或者叫上行/TX）和接收端（或者叫下行/RX）都有。在發(fā)送端主要包括聲音的采集引入的延時(shí)、前處理算法引入的延時(shí)和編碼算法引入的時(shí)延。聲音采集時(shí)通常5Ms或者10Ms從采集DMA中取一次語音數(shù)據(jù)，但是編碼時(shí)多數(shù)codec要求的一幀是20Ms（比如AMR-WB），這兩者之間不匹配，就要求采集到的數(shù)據(jù)放在buffer里緩一段時(shí)間，等到幀長時(shí)再取出來去編碼，這就引入了時(shí)延。以一幀20Ms為例，就會(huì)引入20Ms的延時(shí)。前處理算法主要有AEC、ANS、AGC，這些算法都會(huì)引入延時(shí)，這跟濾波器的階數(shù)有關(guān)，階數(shù)越多，延時(shí)越大。編碼算法同前處理算法一樣也引入了延時(shí)。在接收端主要包括端網(wǎng)絡(luò)延時(shí)、解碼算法延時(shí)、后處理算法延時(shí)和播放延時(shí)。端網(wǎng)絡(luò)延時(shí)主要出現(xiàn)在解碼之前的jitter buffer內(nèi)，如果有抗丟包處理（例如FEC）延時(shí)還會(huì)增加（有FEC增加延時(shí)的原因是要等接收到的包到指定個(gè)數(shù)才能做FEC解碼還原出原始包，用FEC抗丟包的原理我在前面的文章（語音通信中提高音質(zhì)的方法）中寫過）。解碼和后處理算法和發(fā)送端的編碼前處理類似有延時(shí)。播放前為了保持播放的流暢性會(huì)在語音數(shù)據(jù)進(jìn)播放DMA前加一級buffer，這也引入了延時(shí)。

2、時(shí)延測量

時(shí)延是過認(rèn)證的必選項(xiàng)。對于語音通信解決方案來說，先得讓時(shí)延低于認(rèn)證指定的值，然后再看有沒有減小的可能。如可以將時(shí)延做到更小，則是該方案的亮點(diǎn)。要測量時(shí)延就得在實(shí)驗(yàn)室搭建一個(gè)理想的端到端的語音通信系統(tǒng)（理想是指網(wǎng)絡(luò)幾乎不引入時(shí)延），同時(shí)兩端均采用該語音方案，這樣就可以用儀器測出端到端的延時(shí)了。測時(shí)延時(shí)，儀器上顯示的時(shí)延是一個(gè)平均值，等通話時(shí)長達(dá)到一定值后就會(huì)穩(wěn)定下來。拿它跟認(rèn)證指定的值比較，如果大于指定值，認(rèn)證是過不了的，先要減小時(shí)延讓它低于指定值。如果低于指定值，則說明該方案有一個(gè)好的起點(diǎn)，可以繼續(xù)減小讓其成為亮點(diǎn)。

用儀器測出來的單向時(shí)延大體上應(yīng)該是終端上各個(gè)模塊引入的時(shí)延之和。要減小時(shí)延首先得搞清楚是哪個(gè)模塊引入的時(shí)延較大。有些模塊引入的時(shí)延是已知固定的，且不能減少，比如信號處理算法模塊。有些模塊引入的時(shí)延是未知的，我們就需要去測量這個(gè)模塊引入的時(shí)延具體是多少。做這些前需要對該語音通信方案的軟件架構(gòu)熟悉，知道方案中有幾個(gè)（除了信號處理算法模塊外）引入時(shí)延的點(diǎn)。這種時(shí)延通常是對buffer的存取引入的時(shí)間差，該怎么測出時(shí)延值呢？我一般用如下的方法：當(dāng)把語音數(shù)據(jù)放進(jìn)buffer時(shí)記下當(dāng)時(shí)的時(shí)間t1，保存在這段數(shù)據(jù)開始的地方（雖然破壞了語音數(shù)據(jù)，不過沒關(guān)系，我們只是用來測延時(shí)，是一種手段，不關(guān)心語音質(zhì)量），當(dāng)從buffer中取出這段語音數(shù)據(jù)時(shí)，再記錄下時(shí)間t2，將t2減去保存在數(shù)據(jù)中的t1就得到本次存取引入的延時(shí)。統(tǒng)計(jì)非常多次（我通常用一萬次）再算平均值，就可以得到這個(gè)點(diǎn)引入的時(shí)延了。下面舉例說明。有一塊可以存5幀（每幀20Ms）的buffer，某一幀語音數(shù)據(jù)放在第三幀處。放時(shí)的時(shí)間是158120毫秒，將這個(gè)值放在放這段數(shù)據(jù)開始的地方。將這段數(shù)據(jù)從buffer里取出來時(shí)的時(shí)間是158180秒，可以算出本次延時(shí)是60Ms（158180-158120=60），統(tǒng)計(jì)10000次，算出延時(shí)總和，再除以10000，得到延時(shí)平均值是58Ms。所以這個(gè)點(diǎn)引入的時(shí)延是58Ms。

3、時(shí)延的減小方法

知道了各個(gè)點(diǎn)引入的時(shí)延大小，下面就要看怎么減小時(shí)延了。這里的減小是指能減小的，有些是不能減小的，比如codec引入的時(shí)延。我用過的方法主要有以下兩種。

1）用減小緩沖深度來減小時(shí)延

這種方法說白了就是讓語音數(shù)據(jù)在buffer里呆的時(shí)間短些，比如以前在buffer里有了3幀（假設(shè)每幀20Ms）語音數(shù)據(jù)才會(huì)從buffer中取出給下一模塊，這樣平均就會(huì)引入60Ms的時(shí)延。如果將3幀改為2 幀，則平均引入的時(shí)延就降為40Ms，這樣就減少了20Ms的時(shí)延。不過用這種方法是有條件的，要確保語音質(zhì)量不下降。改了后要用儀器測，如果長時(shí)測試下語音質(zhì)量不下降就說明這個(gè)改后的值是可以接受的。經(jīng)過試驗(yàn)后找到一個(gè)可以接受的緩沖深度的最小的值，就把這個(gè)值用在方案中。

2）用加速信號處理算法來減少時(shí)延

音頻信號處理中有個(gè)算法叫加速，它是對PCM信號進(jìn)行處理，在不丟失語音信息的前提下把時(shí)長減小，它的原理是WSOLA。比如原PCM數(shù)據(jù)時(shí)長是5秒，經(jīng)過加速處理后變成了4秒，人聽上去信息沒丟失，但是語速變快了。如果在buffer中待播放的PCM數(shù)據(jù)較長，肯定延時(shí)較大，可以通過這種加速算法把要播放的數(shù)據(jù)處理一下，變成短時(shí)長的PCM數(shù)據(jù)，這樣就可以減小延時(shí)了。我第一次做voice engine的時(shí)候，除了減小buffer緩沖深度沒有其他好的方法來減小延時(shí)。后來做了語音加速播放的功能（具體見我前面的文章：音頻處理之語音加速播放），覺得可以用這個(gè)算法來減小延時(shí)。可是當(dāng)時(shí)事情非常多，再加上要做到延時(shí)減小了但同時(shí)也要讓聽者感覺不到在加速播放還有很多細(xì)節(jié)工作要做，也就沒做成。隨著webRTC風(fēng)靡音視頻開發(fā)圈，我也開始關(guān)注。了解到其中的netEQ就有用加速算法來減小延時(shí)的功能，看來英雄所見略同啊。哈哈。同時(shí)我也感覺到要多做東西，見多才能識廣呀，說不定結(jié)合以前做過的東西就能得到解決問題的好的思路呢。當(dāng)然加速減少延時(shí)功能只是netEQ的一部分。netEQ主要是解決網(wǎng)絡(luò)抖動(dòng)延時(shí)丟包等問題來提高語音質(zhì)量的，可以說說目前公開的處理此類問題的最佳方案了。從下篇開始，我將花幾篇文章來詳細(xì)的講講netEQ。netEQ是webRTC中音頻相關(guān)的兩大核心技術(shù)之一（另一個(gè)是前后處理，有AEC/ANS/AGC等），很值得研究。