在智能終端設(shè)備不斷更新?lián)Q代，移動(dòng)通信基礎(chǔ)設(shè)施不斷升級(jí)的大環(huán)境催化下，基于IP網(wǎng)的語音通話（VOIP）的質(zhì)量和穩(wěn)定性取得的長足的進(jìn)步。VOIP以其較傳統(tǒng)PSTN電話更高的音質(zhì)和更低的成本越來越受到大眾的青睞。隨著像聲網(wǎng)Agora.io這樣的VOIP服務(wù)供應(yīng)商的出現(xiàn)，越來越多的廠商開始意識(shí)到自己的應(yīng)用中需要這種最原始自然的溝通方式，而想在短期內(nèi)在自己的應(yīng)用中嵌入多人音視頻通話功能成也變成了可能。

　　為了追求更好的用戶體驗(yàn)，大家也逐漸的從原來出聲就行出圖就行的舊觀念，逐漸轉(zhuǎn)化到了對音視頻質(zhì)量有著更高的要求和期待。但是音頻的問題對于一般開發(fā)者來說比較神秘，很多朋友不太清楚如何全面的評估第三方的音頻引擎，也有不少朋友踩過很多有苦說不出的坑。其中比較典型有幾種聲音：

　　我們花了好多錢買了一套基于硬件的解決方案，開始用的還行，怎么現(xiàn)在越來越卡了？

　　我們評估了個(gè)引擎，自己內(nèi)網(wǎng)測試的時(shí)候感覺聲音很流暢，延時(shí)很小。為什么上線了很多用戶說又卡又延時(shí)啊？

　　我們用WebRTC做了一套方案，iPhone上還好，但是為什么在安卓的機(jī)器上老是有回聲��？

　　為什么我昨天用的還好好的，今天換了個(gè)手機(jī)/地方/網(wǎng)絡(luò)打效果差好多啊？

　　要回答這些問題，我們首先需要搞清楚到底哪些因素會(huì)影響對音頻質(zhì)量的評估。然后我們再來看需要做哪些測試才能比較全面的評估一個(gè)音頻引擎。最后我們討論一下大家比較關(guān)心的WebRTC框架中的音頻模塊如何，是否適合商用？

　　網(wǎng)絡(luò)對音頻質(zhì)量的影響是非常直觀的，如果承載音頻信息的語音包在網(wǎng)絡(luò)傳輸?shù)倪^程中丟失，晚到，或者不均勻的到，就會(huì)造成我們常說的丟包，延時(shí)和抖動(dòng)。

　　從主觀聽感上造成聲音的卡頓和滯后，嚴(yán)重影響通話的質(zhì)量和可懂度。在公共互聯(lián)網(wǎng)上，特別是在遠(yuǎn)距離通信的情況下，如果缺乏足夠的網(wǎng)絡(luò)部署和音頻的丟包對抗技術(shù)，這種情況就會(huì)變得尤為明顯。如果是在內(nèi)網(wǎng)環(huán)境，兩人通話的場景下，聲音可以通過點(diǎn)對點(diǎn)（P2P）的連接互相傳輸，很多網(wǎng)絡(luò)問題容易被單一的測試環(huán)境忽略了。

　　這也是為什么有些同學(xué)在自己的公司內(nèi)網(wǎng)測試時(shí)候感覺延時(shí)小聲音流暢，跑到真實(shí)環(huán)境下就經(jīng)常遇到各種各樣的質(zhì)量問題。

　　另外值得一提的是，除了在傳輸層引起的丟包抖動(dòng)，最后一公里(Last Mile)的問題（路由器，移動(dòng)數(shù)據(jù)網(wǎng)絡(luò)等）也會(huì)引起丟包抖動(dòng)，所以有時(shí)候有的同學(xué)說我們家20M的帶寬，怎么用起來還是卡頓。其實(shí)有時(shí)候路由器反而是產(chǎn)生問題的根源。

　　設(shè)備對于音頻質(zhì)量的影響是相對隱性的，但是往往會(huì)起著決定性的作用。比如iPhone就有著比較好的聲學(xué)設(shè)計(jì)。麥克風(fēng)和揚(yáng)聲器之間的耦合程度較小，這樣你說話經(jīng)揚(yáng)聲器播放產(chǎn)生的回聲在被麥克風(fēng)收錄時(shí)候已經(jīng)有了很大程度的衰減，對回聲消除模塊來說也是一個(gè)利好。另外它有三個(gè)麥克風(fēng)，位于設(shè)備底部的麥克風(fēng)主要收取說話人的聲音，位于背部的麥克風(fēng)用來拾取背景噪聲，給主麥克風(fēng)做參考，從而更好對人聲做降噪處理，讓對方聽得更清楚。另外位于聽筒附近還有一個(gè)麥克風(fēng)用來感知聽筒附近的噪聲，從而生成一個(gè)反相位的波從聽筒里播放出來抵消這部分噪聲，讓你聽對方也可以聽的更清楚。

　　而設(shè)備的問題在安卓機(jī)上就非常碎片化，我想所有和安卓打過交道的開發(fā)者都沒少聽過適配這兩字。由于每個(gè)設(shè)備揚(yáng)聲器和麥克風(fēng)的屬性都不盡相同，特別是在一些中低端機(jī)型上有些手機(jī)的聲學(xué)設(shè)計(jì)是非常不合理的（嚴(yán)重的麥克風(fēng)揚(yáng)聲器耦合，非線性失真，麥克風(fēng)底噪等），會(huì)使得一些通用的音頻算法（回聲消除，降噪）無法正常工作。這也回答了我們之前的問題，為什么有些同學(xué)測的iPhone覺得不錯(cuò)，但是到一些中低端的安卓機(jī)器上就問題百出。這類問題無論網(wǎng)絡(luò)好壞都會(huì)產(chǎn)生，這時(shí)候就必須有音頻引擎的算法模塊來做對應(yīng)的算法適應(yīng)和適配了。除此之外，在手機(jī)這類非實(shí)時(shí)操作系統(tǒng)上，計(jì)算資源的搶占，錄放音的調(diào)度問題都會(huì)對音頻算法帶來很大的挑戰(zhàn)。要解決這些問題就必須投入大量的資源去研發(fā)和調(diào)試，而解決這類問題的技術(shù)門檻一般都是很高的。

　　物理環(huán)境對音頻的影響更不容易被察覺，但是它在很多情況下會(huì)干擾到音頻引擎的正常工作，從而對用戶的最終聽感產(chǎn)生負(fù)面影響。熟悉音頻算法的朋友都知道，我們在做回聲消除的時(shí)候，需要實(shí)時(shí)估計(jì)出當(dāng)前物理環(huán)境的脈沖響應(yīng)(Impulseresponse)，才能將它和參考信號(hào)(Referencesignal)卷積，從而初步估算出麥克風(fēng)收到的回聲信號(hào)。假設(shè)我們現(xiàn)在身處一個(gè)密閉的會(huì)議室，揚(yáng)聲器播放出來的回聲部分在被麥克風(fēng)收錄時(shí)候就會(huì)摻入很多物理環(huán)境反射路徑帶來的分量，這個(gè)時(shí)候就要考察自適應(yīng)濾波器是否有足夠的能力來覆蓋這種場景了。如果音頻引擎做得不好，就會(huì)導(dǎo)致我們平時(shí)遇到的一些奇怪現(xiàn)象，比如為什么我剛才聽對方好好的，他換了個(gè)小會(huì)議繼續(xù)開會(huì)我就很多奇怪的雜音呢？而事實(shí)上，影響脈沖響應(yīng)的因素遠(yuǎn)不止這些，甚至有研究發(fā)現(xiàn)每一度溫度的變化可能會(huì)導(dǎo)致40dB脈沖響應(yīng)的變化。

　　另外還有很多物理環(huán)境會(huì)對音頻質(zhì)量造成影響。比如近場時(shí)候的尖銳雜音（嘯叫），是由于設(shè)備A的麥克風(fēng)會(huì)直接收錄到設(shè)備B的揚(yáng)聲器播放的聲音，然后又會(huì)傳回設(shè)備B播放出來，形成了一個(gè)正反饋回環(huán)導(dǎo)致的。只要分開一定距離通話或者靜音掉其中一方就會(huì)消失。更直觀的例子比如本地身處嘈雜的環(huán)境下的聽對方會(huì)更困難，對方聽自己也會(huì)有受到噪聲的干擾。再比如剛才說的密閉環(huán)境下，本身想保留的語音信號(hào)也會(huì)受到反射路徑的影響，造成平時(shí)所說的混響(Reverb)，會(huì)讓對方聽到一些失真。

　　從上文的討論中我們可以看到，其實(shí)網(wǎng)絡(luò)，設(shè)備和物理環(huán)境都會(huì)對音頻質(zhì)量造成很大的影響，而且這種影響很多時(shí)候并非很直觀的可以察覺到。如果沒有科學(xué)的評估和定量的分析，很難通過一兩次測試來下比較全面和準(zhǔn)確的結(jié)論。那么我們很自然的會(huì)問，我們需要怎樣來定量和全面的評估一個(gè)音頻引擎呢？要做哪些測試才能覆蓋到盡量多的真是使用場景，同時(shí)又能盡可能的排除各種隨機(jī)的影響因素呢？那么下面這章我就來討論下這個(gè)問題。

　　我們想要定量的分析一個(gè)音頻引擎的優(yōu)劣點(diǎn)，就必須在測試中盡可能的排除網(wǎng)絡(luò)，設(shè)備和物理環(huán)境等因素帶來的隨機(jī)性影響。3GPP，ESTI等通信業(yè)國際標(biāo)準(zhǔn)，對手機(jī)通信的測試環(huán)境方法很多要求和指引，感興趣的同學(xué)可以在參考文獻(xiàn)找到一些資料。簡單的說，我們需要足夠安靜且反射路徑最小化的聲學(xué)環(huán)境來避免周圍的環(huán)境音來影響測試，所以需要有專業(yè)設(shè)計(jì)的消聲室。我們需要可重復(fù)又高保真的發(fā)聲和收音裝置來覆蓋人的正常說話和聽力動(dòng)態(tài)范圍，所以需要人工耳和人工嘴。另外，為了覆蓋更多的真實(shí)場景，我們還需要網(wǎng)損設(shè)備來模擬和控制丟包，需要近似真實(shí)環(huán)境的沉浸式噪音場景，我們需要在人工頭的四周布置高保真的音箱來制造噪聲聲場。

　　要執(zhí)行符合3GPP，ETSI等通信標(biāo)準(zhǔn)的客觀測試，我們需要搭建了類似下圖的測試環(huán)境。以HeadAcoustic的ACQUA系統(tǒng)為例，我們需要：

　　當(dāng)我們搭建好了實(shí)驗(yàn)室的環(huán)境，根據(jù)3GPP的標(biāo)準(zhǔn)，我們可以通過這套環(huán)境來定量的測量到一些端到端的音頻指標(biāo)了。同樣以ACQUA為例，我們可以測量但不限于：

　　客觀測試的一個(gè)重要優(yōu)點(diǎn)是，網(wǎng)絡(luò)設(shè)備物理環(huán)境條件相對可控，可重復(fù)性較強(qiáng)。這些通信標(biāo)準(zhǔn)定義的客觀指標(biāo)也很大程度上可以幫助快速定位音頻問題。但是客觀測試本身也它自己的局限性。首先，要搭建上述的一套科學(xué)的客觀測試環(huán)境，一般需要七位數(shù)字人民幣的預(yù)算，這對很多公司來說已經(jīng)是個(gè)很大的制約了。更重要的是，客觀測試可以暴露一些明顯的問題，但是很難覆蓋到一些細(xì)節(jié)和定位到問題的根源。所以無論是出于成本的考慮還是更細(xì)節(jié)的音頻分析，我們都需要有合理的主觀測試來彌補(bǔ)客觀測試的一些問題。

　　在業(yè)界，音頻主觀測試并沒有可以統(tǒng)一遵循的標(biāo)準(zhǔn)。雖然ITU對音頻主觀測試有一些建議和指引，但是每個(gè)測試都有自身的側(cè)重點(diǎn)設(shè)計(jì)和執(zhí)行也不盡相同。

　　一般比較常用的做法是請足夠多的人來采集有統(tǒng)計(jì)意義的樣本，然后對測試人員做一定的聽音培訓(xùn)。最后根據(jù)信號(hào)失真度，背景侵入度，和總體質(zhì)量等方面來對音頻通話打分。

　　這種方法主要用來比較不同引擎之間的總體主觀感受，如果需要更細(xì)節(jié)的發(fā)現(xiàn)和比較問題，還是需要跟針對性的測試。

　　主觀測試相對來比較靈活，可以不必限定在消聲室中進(jìn)行。但是為了盡量避免我們之前的提到的設(shè)備網(wǎng)絡(luò)環(huán)境的不確定因素，測試人員和被測設(shè)備需要分別放置于兩個(gè)音源隔離的房間。網(wǎng)損的部分，可以使用Linux的TCNetEM模塊模擬，如10%丟包設(shè)置命令為：tc qdisc add dev eth0 root netem loss 10%。噪聲的部分，如果沒有ACQUA等分析系統(tǒng)提供的噪聲源，可以使用NOISEX-92等學(xué)術(shù)研究中常用的語料庫來代替。建議對通話進(jìn)行錄音，這樣可以在測試后重聽和標(biāo)注，更好的分析問題。如果測試的引擎不帶錄音的話，可以在外放的而環(huán)境通過外部設(shè)備來錄制。

　　一般我們先在較好的網(wǎng)絡(luò)狀態(tài)下測試音頻的基礎(chǔ)質(zhì)量，然后慢慢增加丟包率來測試一個(gè)引擎抗丟包的邊界。在tc的隨機(jī)丟包模型下，聲網(wǎng)Agora。io的抗丟包能力一般在70%左右，這部分和一般的音頻引擎還是有比較明顯的差異。另外在細(xì)節(jié)的音頻模塊方面也需要很多針對性的測試，比如回聲消除，降噪，增益控制，近場嘯叫，盲源分離等模塊都可以有非常詳細(xì)的細(xì)節(jié)指標(biāo)可以跟蹤。這里就借用聲網(wǎng)Agora Video Call和某些競品的對比測試報(bào)告，來舉例說明下如何針對不同的算法模塊做一些定量分析。對其他模塊有興趣歡迎聯(lián)系我們討論，這里就不一一展開了。

　　下圖（a）和（b）比較了某競品和聲網(wǎng)SDK在降噪（NS）方面的表現(xiàn)。這里用的是NOISEX-92語料庫中的Voice Babble，混音的信噪比是5dB。通過錄音和定量分析，我們可以看到在算法的收斂時(shí)間，降噪后的殘留噪聲，和有語音時(shí)候的信噪比方面，聲網(wǎng)Agora.io的音頻引擎效果有明顯的優(yōu)勢。

　　圖（a）

　　圖（b）

　　下圖（c）和（d）比較了某競品和聲網(wǎng)Agora.ioSDK在自動(dòng)增益控制（AGC）方面的表現(xiàn)。在會(huì)議場景中這個(gè)參數(shù)會(huì)特別重要。因?yàn)楹苡锌赡艽蠹視?huì)離通話的設(shè)備有一定的距離說話，如果這時(shí)候不經(jīng)過特殊的增益提高，對方會(huì)很難聽清一些參會(huì)者的聲音。從圖中分析后可以發(fā)現(xiàn)，如果兩邊大家都貼近話筒的時(shí)候，錄音的大家差異是不明顯的。但是當(dāng)你測試離麥克風(fēng)有1米甚至2米的情況下，有些競品的聲音就會(huì)變的很小，而有正確的增益控制的引擎就能讓你對音量均衡的聲音。

　　圖（c）

　　圖（d）

　　到這里，大家應(yīng)該對影響音頻質(zhì)量的因素和需要做哪些測試來評估一個(gè)音頻引擎有了一定的概念。有的朋友可能會(huì)說，這個(gè)評估工作看起來都好復(fù)雜，也需要不少資源投入。有沒有簡單點(diǎn)的方法�。柯犝fWebRTC很火，可以直接拿來用嗎？

　　聲網(wǎng)Agora.io公眾號(hào)之前已經(jīng)有一篇關(guān)于WebRTC的優(yōu)缺點(diǎn)分析的文章，有興趣的同學(xué)可以找出來看一下。那篇文章中提到的缺乏服務(wù)器部署，缺乏多人支持等缺陷這里就不贅述了，這里來稍微深入的探討一下如果要用WebRTC音頻模塊來商用會(huì)遇到哪些問題。

　　WebRTC最初是為PC上的瀏覽器通信而設(shè)計(jì)的，所以相關(guān)的音頻算法，不管是從復(fù)雜度還是效果上都是以PC作為主要考量點(diǎn)的。雖然它也提供了像AECM這種專為mobile設(shè)計(jì)的低復(fù)雜度回聲消除算法，但是效果一直被詬病。在其官方論壇也能找不少關(guān)于該算法導(dǎo)致的回聲失真等問題的報(bào)告。而官方的答復(fù)是Won'tFix，理由是算法的已知缺陷。

　　經(jīng)過之前的討論，我們已經(jīng)知道設(shè)備對音頻質(zhì)量有很大的影響。這種影響在五花八門的國產(chǎn)手機(jī)，特別是一些中低端機(jī)型上尤為明顯。如果讓W(xué)ebRTC音頻模塊直接在各種安卓機(jī)上跑的話，會(huì)遇到各種各樣的問題。也有不少朋友現(xiàn)在還沒有從這個(gè)坑里爬出來。這里不僅需要算法來適配補(bǔ)償聲學(xué)設(shè)計(jì)上的一些缺陷，也有不少是因?yàn)橐恍┲行∈謾C(jī)廠商沒有遵循相關(guān)的安卓音頻調(diào)用規(guī)范導(dǎo)致錄放音問題，這時(shí)候還需要做機(jī)型相關(guān)的底層適配。

　　關(guān)于WebRTC音頻模塊的資料并不是很多，要了解每個(gè)算法模塊的細(xì)節(jié)需要花不少時(shí)間，而且需要對信號(hào)處理有比較扎實(shí)基礎(chǔ)的音頻算法工程師才行。很多時(shí)候我們所說的適配只是一個(gè)通用的說法，并不是已經(jīng)有很多開放出來的參數(shù)一個(gè)個(gè)試就能解決問題的。想要達(dá)到比較好的音頻體驗(yàn)，對算法的理解和投入是必須的，否則遇到音頻問題就會(huì)束手無策。雖然

　　WebRTC會(huì)通過自己的論壇和BugReport系統(tǒng)來收集一些用戶問題，但是要期望官方短期內(nèi)解決還是需要多燒燒香的。

　　隨著應(yīng)用的多元化，我們開始需要在App里面定義多于一個(gè)的音頻行為。比如在游戲場景中需要播放游戲音效的同時(shí)進(jìn)行語音，比如在直播場景中主播需要把MP3等音樂文件和錄音混音處理。這些部分都不在WebRTC的考慮范圍之內(nèi)，需要自己團(tuán)隊(duì)來做開發(fā)。

　　陳若非聲網(wǎng)Agora.io資深音頻技術(shù)專家

　　負(fù)責(zé)基礎(chǔ)音頻技術(shù)的架構(gòu)和研發(fā)。畢業(yè)于香港城市大學(xué)Ph.D。主要研究基于模型重建的語音增強(qiáng)技術(shù)，對回聲消除，降噪，增益控制，多麥，音效處理，丟包隱藏等語音技術(shù)有豐富經(jīng)驗(yàn)。曾任職YY基礎(chǔ)技術(shù)研發(fā)部門，及為IEEE權(quán)威語音期刊和會(huì)議擔(dān)任評審工作。