設(shè)備對(duì)于音頻質(zhì)量的影響是相對(duì)隱性的，但是往往會(huì)起著決定性的作用。iPhone就有著比較好的聲學(xué)設(shè)計(jì)：

　　但是，設(shè)備的問(wèn)題在安卓機(jī)上就非常碎片化。所有和安卓打過(guò)交道的開(kāi)發(fā)者都沒(méi)少聽(tīng)過(guò)適配這兩字。由于每個(gè)設(shè)備揚(yáng)聲器和麥克風(fēng)的屬性都不盡相同，特別是在一些中低端機(jī)型上，聲學(xué)設(shè)計(jì)是非常不合理的（嚴(yán)重的麥克風(fēng)揚(yáng)聲器耦合，非線(xiàn)性失真，麥克風(fēng)底噪等），會(huì)使得一些通用的音頻算法（回聲消除，降噪）無(wú)法正常工作。這也回答了我們之前的問(wèn)題，為什么有些同學(xué)測(cè)的iPhone覺(jué)得不錯(cuò)，但是到一些中低端的安卓機(jī)器上就問(wèn)題百出。這類(lèi)問(wèn)題無(wú)論網(wǎng)絡(luò)好壞都會(huì)產(chǎn)生，這時(shí)候就必須有音頻引擎的算法模塊來(lái)做對(duì)應(yīng)的算法適應(yīng)和適配了。

　　除此之外，在手機(jī)這類(lèi)非實(shí)時(shí)操作系統(tǒng)上，計(jì)算資源的搶占，錄放音的調(diào)度問(wèn)題都會(huì)對(duì)音頻算法帶來(lái)很大的挑戰(zhàn)。要解決這些問(wèn)題就必須投入大量的資源去研發(fā)和調(diào)試，而解決這類(lèi)問(wèn)題的技術(shù)門(mén)檻一般都是很高的。

　　物理環(huán)境對(duì)音頻的影響更不容易被察覺(jué)，但是它在很多情況下會(huì)干擾到音頻引擎的正常工作，從而對(duì)用戶(hù)的最終聽(tīng)感產(chǎn)生負(fù)面影響。熟悉音頻算法的朋友都知道，我們?cè)谧龌芈曄�除的時(shí)候，需要實(shí)時(shí)估計(jì)出當(dāng)前物理環(huán)境的脈沖響應(yīng)(Impulseresponse)，才能將它和參考信號(hào)(Reference signal)卷積，從而初步估算出麥克風(fēng)收到的回聲信號(hào)。

　　假設(shè)我們現(xiàn)在身處一個(gè)密閉的會(huì)議室，揚(yáng)聲器播放出來(lái)的回聲部分，在被麥克風(fēng)收錄時(shí)，就會(huì)摻入很多物理環(huán)境反射路徑帶來(lái)的分量，這個(gè)時(shí)候就要考察自適應(yīng)濾波器是否有足夠的能力來(lái)覆蓋這種場(chǎng)景了。如果音頻引擎做得不好，就會(huì)導(dǎo)致我們平時(shí)遇到的一些奇怪現(xiàn)象：比如為什么我剛才聽(tīng)對(duì)方好好的，他換了個(gè)小會(huì)議室繼續(xù)開(kāi)會(huì)，我就聽(tīng)到很多奇怪的雜音呢？事實(shí)上，影響脈沖響應(yīng)的因素遠(yuǎn)不止這些，甚至有研究發(fā)現(xiàn)每一度溫度的變化可能會(huì)導(dǎo)致40dB脈沖響應(yīng)的變化。

　　另外還有很多物理環(huán)境會(huì)對(duì)音頻質(zhì)量造成影響。舉例：

　　網(wǎng)絡(luò)，設(shè)備和物理環(huán)境都會(huì)對(duì)音頻質(zhì)量造成很大的影響，而且這種影響很多時(shí)候并非很直觀的可以察覺(jué)到。如果沒(méi)有科學(xué)的評(píng)估和定量的分析，很難通過(guò)一兩次測(cè)試來(lái)下比較全面和準(zhǔn)確的結(jié)論。

　　下一章，會(huì)告訴你：我們需要怎樣來(lái)定量和全面的評(píng)估一個(gè)音頻引擎呢？要做哪些測(cè)試才能覆蓋到盡量多的真是使用場(chǎng)景，同時(shí)又能盡可能的排除各種隨機(jī)的影響因素呢？

　　我們想要定量的分析一個(gè)音頻引擎的優(yōu)劣點(diǎn)，就必須在測(cè)試中盡可能的排除網(wǎng)絡(luò)、設(shè)備和物理環(huán)境等因素帶來(lái)的隨機(jī)性影響。3GPP，ESTI等通信業(yè)國(guó)際標(biāo)準(zhǔn)，對(duì)手機(jī)通信的測(cè)試環(huán)境方法很多要求和指引，感興趣的同學(xué)可以在參考文獻(xiàn)找到一些資料。簡(jiǎn)單的說(shuō)，我們需要：

　　近似真實(shí)環(huán)境的沉浸式噪音場(chǎng)景。我們需要在人工頭的四周布置高保真的音箱來(lái)制造噪聲聲場(chǎng)。

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

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

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

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

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

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

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

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

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

　　圖（a）競(jìng)品

　　圖（b）聲網(wǎng)Agora.io

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

　　圖（c）競(jìng)品

　　圖（d）聲網(wǎng)Agora.io

　　WebRTC的音頻引擎怎么樣？直接拿過(guò)來(lái)用可以嗎？

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

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

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

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

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

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

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

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