語音通信   測量

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

1、時延產生

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

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

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

2、時延測量

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

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

3、時延的減小方法

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

1）用減小緩沖深度來減小時延

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

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

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