淺談傳統語音通訊和APP語音通訊音頻軟件開發之不一樣點

本人在傳統的語音通訊公司作過手機和IP電話上的語音軟件開發，也在移動互聯網公司作過APP上的語音軟件開發。如今帶實時語音通訊功能的APP有好多，主流的有微信語音、QQ電話、釘釘等，固然也包括我開發過的那款APP（那款APP在實時通訊APP排名中一直靠前）。既然都作語音軟件開發，那確定有不少共同的地方，好比須要相同的語音專業知識，都有語音前處理、編解碼、傳輸等。經過本身的觀察，也有一些不一樣的地方。咱們今天主要聊聊這些不一樣點。

 

1，在傳統語音通訊公司都是在具體硬件上開發音頻軟件。有了硬件就要有相應的驅動，在Linux/Android上就是ALSA相關的驅動軟件開發。對於前處理、編解碼、傳輸等模塊，既能夠在底層作也能夠在偏上面的層次作，這取決於軟件架構。我曾經在Linux平臺上硬件同樣軟件需求同樣的狀況下因爲軟件架構不同開發過兩套語音方案。一套方案是驅動在kernel space作，前處理、編解碼、傳輸等在user space作。另外一套方案是驅動和前處理、編解碼、傳輸等所有在kernel space作。之因此要作兩套方案是由於第一套方案的性能不夠好，尤爲表如今one way delay上。

 

在移動互聯網公司作APP上的語音軟件都是在上層作開發。驅動等對開發人員是黑盒子，開發人員要作的有前處理、編解碼、傳輸等，用好系統提供的API就能夠了。以Android爲例，對作APP來講用好media framework裏提供的audio相關的（AudioRecord/AudioTrack等）API 就能夠了。

 

2，上面說過在傳統語音通訊公司裏都是在具體硬件上開發軟件，一些音頻相關的參數就只有一套，在這個硬件上調好了就能夠了。而在APP上作語音軟件開發，不針對具體的硬件。可是一些音頻參數要依賴於硬件，不一樣的硬件上參數不同，一個手機上調的效果很好的參數到另外一個是手機上可能效果就很糟糕，因此在APP上作音頻軟件開發一個很重要的工做就是硬件適配。在不一樣的機型上用不一樣的參數，最起碼也要把主流的機型適配好，一些用戶量大的APP要適配上百款甚至幾百款機型。以回聲消除爲例，它的一個很重要的參數就是從speaker（遠端）出來到mic（近端）進去的時延，不一樣的機型時延不同，這主要由於兩點：1）硬件不同，2）作APP都是在上層作，它要從底層拿到遠端和近端的PCM數據，不一樣的手機底層實現不同，時延也會不同。開發時就要把儘量多的機型上的時延獲得保存起來，用戶使用時根據不一樣的機型給出不一樣的時延值。

 

3，在傳統通訊公司開發語音軟件，若是作有線產品，codec通常選用ITU-T的G系列（G711/G722/G726/G729等），若是作無線產品，codec通常選用3GPP的AMR系列（AMR-NB/AMR-WB等）。在APP上作語音軟件開發，codec更多的會選用互聯網陣營裏提出來的iLBC/OPUS等。如今作語音通訊，基本上造成了兩大陣營，即以ITU-T/3GPP爲表明的傳統陣營和互聯網陣營，在codec上都有各自的演進策略。傳統陣營會演進到EVS（支持語音和音樂，最高48K採樣），互聯網陣營會演進到OPUS（支持語音和音樂，最高96K採樣）。中國移動已要求移動終端17年末可選支持EVS，18年中必須支持EVS，傳統陣營要求這麼快演進也是被形勢所逼。前幾天微信語音功能進行了更新，能夠像系統電話那樣來接聽微信語音電話，又要革電話的命了，之前革了短信的命。我的以爲互聯網公司在語音codec上選擇iLBC/OPUS還有一個緣由是由於他們的語音方案多基於開源的來作，好比webRTC，而這些codec是開源方案裏自然支持的，互聯網又要求快，他們必然會選擇這些已經調試適配好的codec。

 

4，在傳統通訊公司開發語音軟件，必定要嚴格遵照各類協議（主要有3GPP/ITU-T/RFC的），不能有本身私有的協議，由於要過互通性測試。運營商在採購通訊設備時通常會採購多家設備商的（採購多家設備商的設備有多方面緣由，其中之一就是不想讓一家設備商一家獨大造成壟斷從而受制於他），通訊終端更是多種多樣，你們必須遵照相同的協議才能互通，因此必定要嚴格遵照各類協議。

 

在移動互聯網公司開發APP上的語音軟件，客戶端（前臺）是本身開發維護，服務器（後臺）也是本身開發維護，即全部都是本身開發維護，不存在跟其餘廠家的產品互通。這樣就會用不少私有協議。我開發過的那款APP就用了好多私有協議，有的是本身提出來的，有的是對已有公開協議的改造。這些協議若是有文檔還好，若是沒文檔在看代碼時就會特別累。

 

5，在語音通訊過程當中，通常有一半左右的時間在講話，剩下的時間在聽。在傳統通訊公司開發語音軟件，爲了節省帶寬和下降功耗，會對採集到的聲音作能量檢測（叫靜音檢測VAD），當聲音能量低於設定的門限值時就不發語音包給對法，取而代之的是發SID（Silence Insertion Descriptor）包給對方，一般是每隔一段時間發一個這樣的SID包，好比AMR-WB中的160ms，並且這種包的payload size很小。這相對於每隔20ms發一個的語音包來講大大的節省了帶寬。接收端收到SID後就會作CNG，產生溫馨噪聲。因爲不須要再作編解碼，這也必定程度上下降了功耗。在移動互聯網公司開發APP上的語音軟件，一般不考慮這些，全部採集到的語音數據都編碼用RTP打包發給對方。我開發過的以及微信都是這麼作的。

 

6，傳統語音通訊都是有QoS保障的，語音包的優先級是高於通常數據包的，會有一些措施來作丟包補償，可是措施不會特別多，常見的有PLC等。APP上的語音又叫OTT（Over The Top，是指互聯網公司越過運營商發展基於開放互聯網的各類音視頻及數據服務業務）語音，沒有QoS保障，爲了保證語音質量，一般會採起多種補償方法，常見的有重傳、FEC等。在弱網狀況下這些方法雖然會提升音質，可是要增長流量。若是幾種補償方法同時用，可能會成倍或者幾倍的增長流量。

 

7，傳統通訊網絡一般會劃分爲終端、接入網、核心網等不一樣的網元，以下圖：

                                          

做爲語音通訊，終端會把採集到的語音編碼後打包通過attached的接入網設備核心網設備到對方attached的接入網設備再到對方終端播放出來。通常接入網設備和核心網設備只會透傳語音數據不會修改語音數據。

 

在APP上開發語音軟件，通常採用client-server機制，以下圖。

                                                    

Client A 與Client B進行語音通訊，A把語音數據發給B。A先把語音數據發給server的PORT A，server會把PORT A的數據路由到PORT B，再由PORT B把語音數據發給Client B。爲了保證語音質量，通常會作兩次補償，先在server的PORT A上根據丟包率等作一次補償，儘量復原出Client A發出的語音數據。再在Client B上作補償，儘量復原出PORT B發出的語音數據。也就是說server會對客戶端發過來的語音數據作修改的，而不是透傳的。

 

8，在傳統通訊公司作語音軟件開發，必定要過運營商的入網認證，包括各類場景下的語音質量（MOS值）、one-way-delay、round-trip-delay等指標。這些指標必定要過，否則拿不到入網證，拿不到入網證也就不能賣產品了。這些指標一般都是拿儀器測是否經過，要想過運營商的指標，公司通常都會有音頻實驗室，裏面放着運營商指定的各類儀器，來模擬指定的各類場景。本身公司實驗室裏指標測過了纔有信心拿到運營商指定的實驗室去測。過認證是一個很痛苦的過程，由於這些都是系統性的問題，解決起來都是不容易的，有可能某個指標花了很長時間解決都不達標。話說回來，解決這些系統性問題的過程也是本身能力提升的過程，整個指標一遍作下來，能力會有一個大的提升。

 

在移動互聯網公司作APP上的語音軟件開發，不會有入網認證，任什麼時候候均可以發佈產品。通常公司也不會建音頻實驗室，由於建一個音頻實驗室花費較大（像騰X這樣的巨頭是有的，它作的很專業，它的兩款APP產品這麼大的用戶量要求它必須作的很專業，作的不專業音質很差會把產品口碑作差的，並且這點花費對它來講不算什麼）。各類場景下的語音質量等指標沒有一個確切的數據。用戶下載了APP用後以爲語音質量好就會繼續用，以爲語音質量很差的話就會卸掉不會再用了。

 

以上就是我基於作過的公司觀察到的一些不一樣點，有可能有遺漏，後面想到了再補上。也有可能其餘移動互聯網公司作法有不一樣的地方，歡迎你們補充。