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