語音通話開發，對於一般開發者來說比較神秘，很多朋友不太清楚如何全面的評估第三方的音頻引擎，如何科學的選擇一家靠譜的語音通話服務供應商。
很多朋友還停留在這樣的初級階段：把demo調通，找幾個人喂喂喂......憑自己優異的聽覺感受一下。整個測試過程就完成了，廠商也就這麼「愉快」的選定了。但是，少年！如果你這樣選，你很有可能遇到下面的這些坑：
我們花了好多錢買了一套基於硬體的解決方案，開始用的還行，怎麼現在越來越卡了？我們評估了個引擎，自己內網測試的時候感覺聲音很流暢，延時很小。為什麼上線了很多用戶說又卡又延時啊？我們用WebRTC做了一套方案，iPhone上還好，但是為什麼在安卓的機器上老是有回聲啊？為什麼我昨天用的還好好的，今天換了個手機/地方/網絡打效果差好多啊？這篇文章，就會教你如何科學的選擇一家靠譜的語音通話服務供應商。這是本文提綱。今天看不完不要緊，收藏起來用到的時候拿出來翻翻。
首先，普及一下，哪些因素會影響對音頻質量的評估。然後，我們再來看需要做哪些測試。最後，我們討論一下大家比較關心的WebRTC框架中的音頻模塊如何，是否適合商用？文章有點長，看不完不要緊，收藏起來，用到的時候拿出來翻翻。
影響音頻質量和穩定性的因素到底有哪些呢？
1.網絡（丟包延時抖動）
網絡對音頻質量的影響是非常直觀的，如果承載音頻信息的語音包在網絡傳輸的過程中丟失，晚到，或者不均勻的到，就會造成我們常說的丟包，延時和抖動。
從主觀聽感上造成聲音的卡頓和滯後，嚴重影響通話的質量和可懂度。在公共網際網路上，特別是在遠距離通信的情況下，如果缺乏足夠的網絡部署和音頻的丟包對抗技術，這種情況就會變得尤為明顯。如果是在內網環境，兩人通話的場景下，聲音可以通過點對點（P2P）的連接互相傳輸，很多網絡問題容易被單一的測試環境忽略了。
這也是為什麼有些同學在自己的公司內網測試時候感覺延時小聲音流暢，跑到真實環境下就經常遇到各種各樣的質量問題。
另外值得一提的是，除了在傳輸層引起的丟包抖動，最後一公裡(LastMile)的問題（路由器，移動數據網絡等）也會引起丟包抖動，所以有時候有的同學說我們家20M的帶寬，怎麼用起來還是卡頓。其實有時候是因為你家路由器太破了。
2.設備（聲學設計，計算能力）
設備對於音頻質量的影響是相對隱性的，但是往往會起著決定性的作用。iPhone就有著比較好的聲學設計：
麥克風和揚聲器之間的耦合程度較小，這樣你說話經揚聲器播放產生的回聲，在被麥克風收錄時候已經有了很大程度的衰減，對回聲消除模塊來說也是一個利好。另外它有三個麥克風：位於設備底部的麥克風，主要收取說話人的聲音；位於背部的麥克風，用來拾取背景噪聲，給主麥克風做參考，從而更好對人聲做降噪處理，讓對方聽得更清楚；位於聽筒附近的麥克風，用來感知聽筒附近的噪聲，從而生成一個反相位的波從聽筒裡播放出來抵消這部分噪聲，讓你聽對方也可以聽的更清楚。但是，設備的問題在安卓機上就非常碎片化。所有和安卓打過交道的開發者都沒少聽過適配這兩字。由於每個設備揚聲器和麥克風的屬性都不盡相同，特別是在一些中低端機型上，聲學設計是非常不合理的（嚴重的麥克風揚聲器耦合，非線性失真，麥克風底噪等），會使得一些通用的音頻算法（回聲消除，降噪）無法正常工作。這也回答了我們之前的問題，為什麼有些同學測的iPhone覺得不錯，但是到一些中低端的安卓機器上就問題百出。這類問題無論網絡好壞都會產生，這時候就必須有音頻引擎的算法模塊來做對應的算法適應和適配了。
除此之外，在手機這類非實時作業系統上，計算資源的搶佔，錄放音的調度問題都會對音頻算法帶來很大的挑戰。要解決這些問題就必須投入大量的資源去研發和調試，而解決這類問題的技術門檻一般都是很高的。
3.物理環境（密閉環境，噪聲，嘯叫等）
物理環境對音頻的影響更不容易被察覺，但是它在很多情況下會干擾到音頻引擎的正常工作，從而對用戶的最終聽感產生負面影響。熟悉音頻算法的朋友都知道，我們在做回聲消除的時候，需要實時估計出當前物理環境的脈衝響應(Impulseresponse)，才能將它和參考信號(Reference signal)卷積，從而初步估算出麥克風收到的回聲信號。
假設我們現在身處一個密閉的會議室，揚聲器播放出來的回聲部分，在被麥克風收錄時，就會摻入很多物理環境反射路徑帶來的分量，這個時候就要考察自適應濾波器是否有足夠的能力來覆蓋這種場景了。如果音頻引擎做得不好，就會導致我們平時遇到的一些奇怪現象：比如為什麼我剛才聽對方好好的，他換了個小會議室繼續開會，我就聽到很多奇怪的雜音呢？事實上，影響脈衝響應的因素遠不止這些，甚至有研究發現每一度溫度的變化可能會導致40dB脈衝響應的變化。
另外還有很多物理環境會對音頻質量造成影響。舉例：
近場時候的尖銳雜音（嘯叫），是由於設備A的麥克風會直接收錄到設備B的揚聲器播放的聲音，然後又會傳回設備B播放出來，形成了一個正反饋迴環導致的。只要分開一定距離通話或者靜音掉其中一方就會消失。本地身處嘈雜的環境下的聽對方會更困難，對方聽自己也會有受到噪聲的幹擾。剛才說的密閉環境下，本身想保留的語音信號也會受到反射路徑的影響，造成平時所說的混響(Reverb)，會讓對方聽到一些失真。網絡，設備和物理環境都會對音頻質量造成很大的影響，而且這種影響很多時候並非很直觀的可以察覺到。如果沒有科學的評估和定量的分析，很難通過一兩次測試來下比較全面和準確的結論。
下一章，會告訴你：我們需要怎樣來定量和全面的評估一個音頻引擎呢？要做哪些測試才能覆蓋到儘量多的真是使用場景，同時又能儘可能的排除各種隨機的影響因素呢？
要全面的評估一個第三方音頻引擎需要做哪些測試？
1.客觀測試
我們想要定量的分析一個音頻引擎的優劣點，就必須在測試中儘可能的排除網絡、設備和物理環境等因素帶來的隨機性影響。3GPP，ESTI等通信業國際標準，對手機通信的測試環境方法很多要求和指引，感興趣的同學可以在參考文獻找到一些資料。簡單的說，我們需要：
專業設計的消聲室。我們需要足夠安靜且反射路徑最小化的聲學環境來避免周圍的環境音來影響測試。人工耳和人工嘴。我們需要可重複又高保真的發聲和收音裝置來覆蓋人的正常說話和聽力動態範圍。網損設備。為了覆蓋更多的真實場景，我們需要網損設備來模擬和控制丟包。近似真實環境的沉浸式噪音場景。我們需要在人工頭的四周布置高保真的音箱來製造噪聲聲場。
要執行符合3GPP，ETSI等通信標準的客觀測試，我們需要搭建了類似下圖的測試環境。以Head Acoustic的ACQUA系統為例，我們需要：
將被測設備(DUT)置於消聲室內，根據聽筒，耳機和外放模式對應的標準距離和方法固定被測設備。參考設備(RD)放在消聲室外，通過Line-in線從測量前端(MFE)輸入標準的語音序列。做發送端的測量時，DUT接收到人工嘴的語音信號，經過對應的音頻模塊和網絡傳輸處理，由消聲室外的RD收到解碼並送入MFE計算得分。做接收端的測量時，參考信號由MFE灌入RD，經過網絡傳輸被DUT收到解碼播放，人工耳記錄下從DUT播放出來的聲音與參考信號比較計算得分。網損模擬裝置控制在發送端或者接收端加入不同類型的丟包，延時和抖動，來測量不利網絡環境下的引擎表現。背景噪聲模擬裝置在消聲室環境中製造不同信噪比和噪聲類型的環境噪聲，測試音頻模塊的降噪效果。當我們搭建好了實驗室的環境，根據3GPP的標準，我們可以通過這套環境來定量的測量到一些端到端的音頻指標了。以ACQUA為例，我們可以測量以下數據，包括但不限於：
End-to-End Voice Delay（ms）：端到端延時，記錄從RD到DUT的端到端的語音延時，涵蓋設備和網絡的延時。Echo Attenuation（dB）：回聲抑制，測量回聲被抑制了多少，單位是分貝，一般>60dB的數值回聲就不太容易被感知到了。POLQA：ITU較新的評估語音質量的指標，是以前PESQ的升級版，可以測量32KHz的採樣率的語音。一般都通俗的把這類語音質量的評分稱為MOS分，1-5分越高說明語音質量越好。3QUEST：同樣是類似MOS分的語音質量測量，但是專門在噪聲環境下進行，噪聲聲場需要有嚴格規定，噪聲序列還需要參考相關標準。Loudness Rating(dB)：響度評分，測量人工耳可以聲壓級(SPL)，一般在[-20，20]範圍內比較理想。Idle Channel Noise(dB)：空閒信道噪聲，測量在沒有語音活躍的狀態下噪聲的舒適度。這個值一般不高於-50dBFrequency Response(dB):頻響，在相關標準中有頻響曲線的掩蔽區間，測量分對應的是真實頻響高於掩蔽區間的分貝數，所以越高越好。Signal-to-Distortionratio(dB)：信號失真比，在MFE記錄下語音信號和失真直接的比值，數值越高說明語音保真度越高。Double Talk(dB)：雙講，記錄下語音在近端遠端同時說話的時候的抑制情況，分數越低，說明雙講透明度越高，也就是語音的保留度更好。客觀測試的一個重要優點是，網絡設備物理環境條件相對可控，可重複性較強。這些通信標準定義的客觀指標也很大程度上可以幫助快速定位音頻問題。但是客觀測試本身也它自己的局限性。首先，要搭建上述的一套科學的客觀測試環境，一般需要七位數字人民幣的預算，這對很多公司來說已經是個很大的制約了。更重要的是，客觀測試可以暴露一些明顯的問題，但是很難覆蓋到一些細節和定位到問題的根源。所以無論是出於成本的考慮還是更細節的音頻分析，我們都需要有合理的主觀測試來彌補客觀測試的一些問題。
2.主觀測試
在業界，音頻主觀測試並沒有可以統一遵循的標準。雖然ITU對音頻主觀測試有一些建議和指引，但是每個測試都有自身的側重點設計和執行也不盡相同。
一般比較常用的做法是請足夠多的人來採集有統計意義的樣本，然後對測試人員做一定的聽音培訓。最後根據信號失真度，背景侵入度，和總體質量等方面來對音頻通話打分。
這種方法主要用來比較不同引擎之間的總體主觀感受，如果需要更細節的發現和比較問題，還是需要跟針對性的測試。
主觀測試相對來比較靈活，可以不必限定在消聲室中進行。但是為了儘量避免我們之前的提到的設備網絡環境的不確定因素，測試人員和被測設備需要分別放置於兩個音源隔離的房間。網損的部分，可以使用Linux的TCNetEM模塊模擬，如10%丟包設置命令為：tcqdiscadddeveth0rootnetemloss10%。噪聲的部分，如果沒有ACQUA等分析系統提供的噪聲源，可以使用NOISEX-92等學術研究中常用的語料庫來代替。建議對通話進行錄音，這樣可以在測試後重聽和標註，更好的分析問題。如果測試的引擎不帶錄音的話，可以在外放的而環境通過外部設備來錄製。
一般我們先在較好的網絡狀態下測試音頻的基礎質量，然後慢慢增加丟包率來測試一個引擎抗丟包的邊界。在tc的隨機丟包模型下，聲網Agora.io的抗丟包能力一般在70%左右，這部分和一般的音頻引擎還是有比較明顯的差異。另外在細節的音頻模塊方面也需要很多針對性的測試，比如回聲消除，降噪，增益控制，近場嘯叫，盲源分離等模塊都可以有非常詳細的細節指標可以跟蹤。這裡就借用聲網Agora Video Call和某些競品的對比測試報告，來舉例說明下如何針對不同的算法模塊做一些定量分析。對其他模塊有興趣歡迎聯繫我們討論，這裡就不一一展開了。
下圖（a）和（b）比較了某競品和聲網SDK在降噪（NS）方面的表現。這裡用的是NOISEX-92語料庫中的Voice Babble，混音的信噪比是5dB。通過錄音和定量分析，我們可以看到在算法的收斂時間，降噪後的殘留噪聲，和有語音時候的信噪比方面，聲網Agora.io的音頻引擎效果有明顯的優勢。
圖（a）競品
圖（b）聲網Agora.io
下圖（c）和（d）比較了某競品和聲網Agora.ioSDK在自動增益控制（AGC）方面的表現。在會議場景中這個參數會特別重要。因為很有可能大家會離通話的設備有一定的距離說話，如果這時候不經過特殊的增益提高，對方會很難聽清一些參會者的聲音。從圖中分析後可以發現，如果兩邊大家都貼近話筒的時候，錄音的大家差異是不明顯的。但是當你測試離麥克風有1米甚至2米的情況下，有些競品的聲音就會變的很小，而有正確的增益控制的引擎就能讓你對音量均衡的聲音。
圖（c）競品
圖（d）聲網Agora.io
WebRTC的音頻引擎怎麼樣？直接拿過來用可以嗎？
到這裡，大家應該對影響音頻質量的因素和需要做哪些測試來評估一個音頻引擎有了一定的概念。有的朋友可能會說，這個評估工作看起來都好複雜，也需要不少資源投入。有沒有簡單點的方法啊？聽說WebRTC很火，可以直接拿來用嗎？
聲網Agora.io公眾號之前已經有一篇關於WebRTC的優缺點分析的文章。文中提到的缺乏伺服器部署，缺乏多人支持等缺陷這裡就不贅述了，這裡來稍微深入的探討一下如果要將WebRTC音頻模塊商用，會遇到哪些問題。
1.移動端的優化不夠
WebRTC最初是為PC上的瀏覽器通信而設計的，所以相關的音頻算法，不管是從複雜度還是效果上都是以PC作為主要考量點的。雖然它也提供了像AECM這種專為mobile設計的低複雜度回聲消除算法，但是效果一直被詬病。在其官方論壇也能找不少關於該算法導致的回聲失真等問題的報告。而官方的答覆是Won'tFix，理由是算法的已知缺陷。
2.對國產手機的「水土不服」
經過之前的討論，我們已經知道設備對音頻質量有很大的影響。這種影響在五花八門的國產手機，特別是一些中低端機型上尤為明顯。如果讓WebRTC音頻模塊直接在各種安卓機上跑的話，會遇到各種各樣的問題。也有不少朋友現在還沒有從這個坑裡爬出來。這裡不僅需要算法來適配補償聲學設計上的一些缺陷，也有不少是因為一些中小手機廠商沒有遵循相關的安卓音頻調用規範導致錄放音問題，這時候還需要做機型相關的底層適配。
3.非商業運營，無文檔無售後，遇到問題不好查
關於WebRTC音頻模塊的資料並不是很多，要了解每個算法模塊的細節需要花不少時間，而且需要對信號處理有比較紮實基礎的音頻算法工程師才行。很多時候我們所說的適配只是一個通用的說法，並不是已經有很多開放出來的參數一個個試就能解決問題的。想要達到比較好的音頻體驗，對算法的理解和投入是必須的，否則遇到音頻問題就會束手無策。雖然
WebRTC會通過自己的論壇和BugReport系統來收集一些用戶問題，但是要期望官方短期內解決，還是需要多燒燒香的。
4.對複雜的應用場景支持不夠
隨著應用的多元化，我們開始需要在App裡面定義多於一個的音頻行為。比如在遊戲場景中需要播放遊戲音效的同時進行語音，比如在直播場景中主播需要把MP3等音樂文件和錄音混音處理。這些部分都不在WebRTC的考慮範圍之內，需要自己團隊來做開發。
結論
網絡，設備，物理環境都會影響音頻質量，測試評估不要局限於單一環境。全面的評估一個實時語音引擎需要科學的測試環境搭建和主客觀測試流程。要自己實現實時語音通話功能需要對音頻有深入的研究和理解，不要輕信集成開源項目可以一勞永逸。如果沒有足夠的開發資源和時間成本來自研實時語音引擎，儘量選擇對音頻有理解、有售後，靠譜的供應商。[本文作者]
陳若非聲網Agora.io資深音頻技術專家
負責基礎音頻技術的架構和研發。畢業於香港城市大學Ph.D。主要研究基於模型重建的語音增強技術，對回聲消除，降噪，增益控制，多麥，音效處理，丟包隱藏等語音技術有豐富經驗。曾任職YY基礎技術研發部門，及為IEEE權威語音期刊和會議擔任評審工作。