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