語(yǔ)音通話開發(fā)，對(duì)于一般開發(fā)者來(lái)說比較神秘，很多朋友不太清楚如何全面的評(píng)估第三方的音頻引擎，如何科學(xué)的選擇一家靠譜的語(yǔ)音通話服務(wù)供應(yīng)商。
很多朋友還停留在這樣的初級(jí)階段：把demo調(diào)通，找?guī)讉�(gè)人喂喂喂......憑自己優(yōu)異的聽覺感受一下。整個(gè)測(cè)試過程就完成了，廠商也就這么“愉快”的選定了。但是，少年！如果你這樣選，你很有可能遇到下面的這些坑：
- 我們花了好多錢買了一套基于硬件的解決方案，開始用的還行，怎么現(xiàn)在越來(lái)越卡了？
- 我們?cè)u(píng)估了個(gè)引擎，自己內(nèi)網(wǎng)測(cè)試的時(shí)候感覺聲音很流暢，延時(shí)很小。為什么上線了很多用戶說又卡又延時(shí)��？
- 我們用WebRTC做了一套方案，iPhone上還好，但是為什么在安卓的機(jī)器上老是有回聲��？
- 為什么我昨天用的還好好的，今天換了個(gè)手機(jī)/地方/網(wǎng)絡(luò)打效果差好多�。�
這篇文章，就會(huì)教你如何科學(xué)的選擇一家靠譜的語(yǔ)音通話服務(wù)供應(yīng)商。這是本文提綱。今天看不完不要緊，收藏起來(lái)用到的時(shí)候拿出來(lái)翻翻。
- 首先，普及一下，哪些因素會(huì)影響對(duì)音頻質(zhì)量的評(píng)估。
- 然后，我們?cè)賮?lái)看需要做哪些測(cè)試。
- 最后，我們討論一下大家比較關(guān)心的WebRTC框架中的音頻模塊如何，是否適合商用？
文章有點(diǎn)長(zhǎng)，看不完不要緊，收藏起來(lái)，用到的時(shí)候拿出來(lái)翻翻。
影響音頻質(zhì)量和穩(wěn)定性的因素到底有哪些呢？
1.網(wǎng)絡(luò)（丟包延時(shí)抖動(dòng)）
網(wǎng)絡(luò)對(duì)音頻質(zhì)量的影響是非常直觀的，如果承載音頻信息的語(yǔ)音包在網(wǎng)絡(luò)傳輸?shù)倪^程中丟失，晚到，或者不均勻的到，就會(huì)造成我們常說的丟包，延時(shí)和抖動(dòng)。
從主觀聽感上造成聲音的卡頓和滯后，嚴(yán)重影響通話的質(zhì)量和可懂度。在公共互聯(lián)網(wǎng)上，特別是在遠(yuǎn)距離通信的情況下，如果缺乏足夠的網(wǎng)絡(luò)部署和音頻的丟包對(duì)抗技術(shù)，這種情況就會(huì)變得尤為明顯。如果是在內(nèi)網(wǎng)環(huán)境，兩人通話的場(chǎng)景下，聲音可以通過點(diǎn)對(duì)點(diǎn)（P2P）的連接互相傳輸，很多網(wǎng)絡(luò)問題容易被單一的測(cè)試環(huán)境忽略了。
這也是為什么有些同學(xué)在自己的公司內(nèi)網(wǎng)測(cè)試時(shí)候感覺延時(shí)小聲音流暢，跑到真實(shí)環(huán)境下就經(jīng)常遇到各種各樣的質(zhì)量問題。
另外值得一提的是，除了在傳輸層引起的丟包抖動(dòng)，最后一公里(LastMile)的問題（路由器，移動(dòng)數(shù)據(jù)網(wǎng)絡(luò)等）也會(huì)引起丟包抖動(dòng)，所以有時(shí)候有的同學(xué)說我們家20M的帶寬，怎么用起來(lái)還是卡頓。其實(shí)有時(shí)候是因?yàn)槟慵衣酚善魈屏恕?/div>
2.設(shè)備（聲學(xué)設(shè)計(jì)，計(jì)算能力）
設(shè)備對(duì)于音頻質(zhì)量的影響是相對(duì)隱性的，但是往往會(huì)起著決定性的作用。iPhone就有著比較好的聲學(xué)設(shè)計(jì)：
- 麥克風(fēng)和揚(yáng)聲器之間的耦合程度較小，這樣你說話經(jīng)揚(yáng)聲器播放產(chǎn)生的回聲，在被麥克風(fēng)收錄時(shí)候已經(jīng)有了很大程度的衰減，對(duì)回聲消除模塊來(lái)說也是一個(gè)利好。
- 另外它有三個(gè)麥克風(fēng)：位于設(shè)備底部的麥克風(fēng)，主要收取說話人的聲音；位于背部的麥克風(fēng)，用來(lái)拾取背景噪聲，給主麥克風(fēng)做參考，從而更好對(duì)人聲做降噪處理，讓對(duì)方聽得更清楚；位于聽筒附近的麥克風(fēng)，用來(lái)感知聽筒附近的噪聲，從而生成一個(gè)反相位的波從聽筒里播放出來(lái)抵消這部分噪聲，讓你聽對(duì)方也可以聽的更清楚。
但是，設(shè)備的問題在安卓機(jī)上就非常碎片化。所有和安卓打過交道的開發(fā)者都沒少聽過適配這兩字。由于每個(gè)設(shè)備揚(yáng)聲器和麥克風(fēng)的屬性都不盡相同，特別是在一些中低端機(jī)型上，聲學(xué)設(shè)計(jì)是非常不合理的（嚴(yán)重的麥克風(fēng)揚(yáng)聲器耦合，非線性失真，麥克風(fēng)底噪等），會(huì)使得一些通用的音頻算法（回聲消除，降噪）無(wú)法正常工作。這也回答了我們之前的問題，為什么有些同學(xué)測(cè)的iPhone覺得不錯(cuò)，但是到一些中低端的安卓機(jī)器上就問題百出。這類問題無(wú)論網(wǎng)絡(luò)好壞都會(huì)產(chǎn)生，這時(shí)候就必須有音頻引擎的算法模塊來(lái)做對(duì)應(yīng)的算法適應(yīng)和適配了。
除此之外，在手機(jī)這類非實(shí)時(shí)操作系統(tǒng)上，計(jì)算資源的搶占，錄放音的調(diào)度問題都會(huì)對(duì)音頻算法帶來(lái)很大的挑戰(zhàn)。要解決這些問題就必須投入大量的資源去研發(fā)和調(diào)試，而解決這類問題的技術(shù)門檻一般都是很高的。
3.物理環(huán)境（密閉環(huán)境，噪聲，嘯叫等）
物理環(huán)境對(duì)音頻的影響更不容易被察覺，但是它在很多情況下會(huì)干擾到音頻引擎的正常工作，從而對(duì)用戶的最終聽感產(chǎn)生負(fù)面影響。熟悉音頻算法的朋友都知道，我們?cè)谧龌芈曄臅r(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)象：比如為什么我剛才聽對(duì)方好好的，他換了個(gè)小會(huì)議室繼續(xù)開會(huì)，我就聽到很多奇怪的雜音呢？事實(shí)上，影響脈沖響應(yīng)的因素遠(yuǎn)不止這些，甚至有研究發(fā)現(xiàn)每一度溫度的變化可能會(huì)導(dǎo)致40dB脈沖響應(yīng)的變化。
另外還有很多物理環(huán)境會(huì)對(duì)音頻質(zhì)量造成影響。舉例：
- 近場(chǎng)時(shí)候的尖銳雜音（嘯叫），是由于設(shè)備A的麥克風(fēng)會(huì)直接收錄到設(shè)備B的揚(yáng)聲器播放的聲音，然后又會(huì)傳回設(shè)備B播放出來(lái)，形成了一個(gè)正反饋回環(huán)導(dǎo)致的。只要分開一定距離通話或者靜音掉其中一方就會(huì)消失。
- 本地身處嘈雜的環(huán)境下的聽對(duì)方會(huì)更困難，對(duì)方聽自己也會(huì)有受到噪聲的干擾。
- 剛才說的密閉環(huán)境下，本身想保留的語(yǔ)音信號(hào)也會(huì)受到反射路徑的影響，造成平時(shí)所說的混響(Reverb)，會(huì)讓對(duì)方聽到一些失真。
網(wǎng)絡(luò)，設(shè)備和物理環(huán)境都會(huì)對(duì)音頻質(zhì)量造成很大的影響，而且這種影響很多時(shí)候并非很直觀的可以察覺到。如果沒有科學(xué)的評(píng)估和定量的分析，很難通過一兩次測(cè)試來(lái)下比較全面和準(zhǔn)確的結(jié)論。
下一章，會(huì)告訴你：我們需要怎樣來(lái)定量和全面的評(píng)估一個(gè)音頻引擎呢？要做哪些測(cè)試才能覆蓋到盡量多的真是使用場(chǎng)景，同時(shí)又能盡可能的排除各種隨機(jī)的影響因素呢？
要全面的評(píng)估一個(gè)第三方音頻引擎需要做哪些測(cè)試？
1.客觀測(cè)試
我們想要定量的分析一個(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)單的說，我們需要：
- 專業(yè)設(shè)計(jì)的消聲室。我們需要足夠安靜且反射路徑最小化的聲學(xué)環(huán)境來(lái)避免周圍的環(huán)境音來(lái)影響測(cè)試。
- 人工耳和人工嘴。我們需要可重復(fù)又高保真的發(fā)聲和收音裝置來(lái)覆蓋人的正常說話和聽力動(dòng)態(tài)范圍。
- 網(wǎng)損設(shè)備。為了覆蓋更多的真實(shí)場(chǎng)景，我們需要網(wǎng)損設(shè)備來(lái)模擬和控制丟包。
近似真實(shí)環(huán)境的沉浸式噪音場(chǎng)景。我們需要在人工頭的四周布置高保真的音箱來(lái)制造噪聲聲場(chǎng)。
要執(zhí)行符合3GPP，ETSI等通信標(biāo)準(zhǔn)的客觀測(cè)試，我們需要搭建了類似下圖的測(cè)試環(huán)境。以Head Acoustic的ACQUA系統(tǒng)為例，我們需要：
- 將被測(cè)設(shè)備(DUT)置于消聲室內(nèi)，根據(jù)聽筒，耳機(jī)和外放模式對(duì)應(yīng)的標(biāo)準(zhǔn)距離和方法固定被測(cè)設(shè)備。
- 參考設(shè)備(RD)放在消聲室外，通過Line-in線從測(cè)量前端(MFE)輸入標(biāo)準(zhǔn)的語(yǔ)音序列。
- 做發(fā)送端的測(cè)量時(shí)，DUT接收到人工嘴的語(yǔ)音信號(hào)，經(jīng)過對(duì)應(yīng)的音頻模塊和網(wǎng)絡(luò)傳輸處理，由消聲室外的RD收到解碼并送入MFE計(jì)算得分。
- 做接收端的測(cè)量時(shí)，參考信號(hào)由MFE灌入RD，經(jīng)過網(wǎng)絡(luò)傳輸被DUT收到解碼播放，人工耳記錄下從DUT播放出來(lái)的聲音與參考信號(hào)比較計(jì)算得分。網(wǎng)損模擬裝置控制在發(fā)送端或者接收端加入不同類型的丟包，延時(shí)和抖動(dòng)，來(lái)測(cè)量不利網(wǎng)絡(luò)環(huán)境下的引擎表現(xiàn)。
- 背景噪聲模擬裝置在消聲室環(huán)境中制造不同信噪比和噪聲類型的環(huán)境噪聲，測(cè)試音頻模塊的降噪效果。
當(dāng)我們搭建好了實(shí)驗(yàn)室的環(huán)境，根據(jù)3GPP的標(biāo)準(zhǔn)，我們可以通過這套環(huán)境來(lái)定量的測(cè)量到一些端到端的音頻指標(biāo)了。以ACQUA為例，我們可以測(cè)量以下數(shù)據(jù)，包括但不限于：
- End-to-End Voice Delay（ms）：端到端延時(shí)，記錄從RD到DUT的端到端的語(yǔ)音延時(shí)，涵蓋設(shè)備和網(wǎng)絡(luò)的延時(shí)。
- Echo Attenuation（dB）：回聲抑制，測(cè)量回聲被抑制了多少，單位是分貝，一般>60dB的數(shù)值回聲就不太容易被感知到了。
- POLQA：ITU較新的評(píng)估語(yǔ)音質(zhì)量的指標(biāo)，是以前PESQ的升級(jí)版，可以測(cè)量32KHz的采樣率的語(yǔ)音。一般都通俗的把這類語(yǔ)音質(zhì)量的評(píng)分稱為MOS分，1-5分越高說明語(yǔ)音質(zhì)量越好。
- 3QUEST：同樣是類似MOS分的語(yǔ)音質(zhì)量測(cè)量，但是專門在噪聲環(huán)境下進(jìn)行，噪聲聲場(chǎng)需要有嚴(yán)格規(guī)定，噪聲序列還需要參考相關(guān)標(biāo)準(zhǔn)。
- Loudness Rating(dB)：響度評(píng)分，測(cè)量人工耳可以聲壓級(jí)(SPL)，一般在[-20，20]范圍內(nèi)比較理想。
- Idle Channel Noise(dB)：空閑信道噪聲，測(cè)量在沒有語(yǔ)音活躍的狀態(tài)下噪聲的舒適度。這個(gè)值一般不高于-50dB
- Frequency Response(dB):頻響，在相關(guān)標(biāo)準(zhǔn)中有頻響曲線的掩蔽區(qū)間，測(cè)量分對(duì)應(yīng)的是真實(shí)頻響高于掩蔽區(qū)間的分貝數(shù)，所以越高越好。
- Signal-to-Distortionratio(dB)：信號(hào)失真比，在MFE記錄下語(yǔ)音信號(hào)和失真直接的比值，數(shù)值越高說明語(yǔ)音保真度越高。
- Double Talk(dB)：雙講，記錄下語(yǔ)音在近端遠(yuǎn)端同時(shí)說話的時(shí)候的抑制情況，分?jǐn)?shù)越低，說明雙講透明度越高，也就是語(yǔ)音的保留度更好。
客觀測(cè)試的一個(gè)重要優(yōu)點(diǎn)是，網(wǎng)絡(luò)設(shè)備物理環(huán)境條件相對(duì)可控，可重復(fù)性較強(qiáng)。這些通信標(biāo)準(zhǔn)定義的客觀指標(biāo)也很大程度上可以幫助快速定位音頻問題。但是客觀測(cè)試本身也它自己的局限性。首先，要搭建上述的一套科學(xué)的客觀測(cè)試環(huán)境，一般需要七位數(shù)字人民幣的預(yù)算，這對(duì)很多公司來(lái)說已經(jīng)是個(gè)很大的制約了。更重要的是，客觀測(cè)試可以暴露一些明顯的問題，但是很難覆蓋到一些細(xì)節(jié)和定位到問題的根源。所以無(wú)論是出于成本的考慮還是更細(xì)節(jié)的音頻分析，我們都需要有合理的主觀測(cè)試來(lái)彌補(bǔ)客觀測(cè)試的一些問題。
2.主觀測(cè)試
在業(yè)界，音頻主觀測(cè)試并沒有可以統(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è)試人員做一定的聽音培訓(xùn)。最后根據(jù)信號(hào)失真度，背景侵入度，和總體質(zhì)量等方面來(lái)對(duì)音頻通話打分。
這種方法主要用來(lái)比較不同引擎之間的總體主觀感受，如果需要更細(xì)節(jié)的發(fā)現(xià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%。噪聲的部分，如果沒有ACQUA等分析系統(tǒng)提供的噪聲源，可以使用NOISEX-92等學(xué)術(shù)研究中常用的語(yǔ)料庫(kù)來(lái)代替。建議對(duì)通話進(jìn)行錄音，這樣可以在測(cè)試后重聽和標(biāo)注，更好的分析問題。如果測(cè)試的引擎不帶錄音的話，可以在外放的而環(huán)境通過外部設(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)舉例說明下如何針對(duì)不同的算法模塊做一些定量分析。對(duì)其他模塊有興趣歡迎聯(lián)系我們討論，這里就不一一展開了。
下圖（a）和（b）比較了某競(jìng)品和聲網(wǎng)SDK在降噪（NS）方面的表現(xiàn)。這里用的是NOISEX-92語(yǔ)料庫(kù)中的Voice Babble，混音的信噪比是5dB。通過錄音和定量分析，我們可以看到在算法的收斂時(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ì)離通話的設(shè)備有一定的距離說話，如果這時(shí)候不經(jīng)過特殊的增益提高，對(duì)方會(huì)很難聽清一些參會(huì)者的聲音。從圖中分析后可以發(fā)現(xiàn)，如果兩邊大家都貼近話筒的時(shí)候，錄音的大家差異是不明顯的。但是當(dāng)你測(cè)試離麥克風(fēng)有1米甚至2米的情況下，有些競(jìng)品的聲音就會(huì)變的很小，而有正確的增益控制的引擎就能讓你對(duì)音量均衡的聲音。
圖（c）競(jìng)品
圖（d）聲網(wǎng)Agora.io
WebRTC的音頻引擎怎么樣？直接拿過來(lái)用可以嗎？
到這里，大家應(yīng)該對(duì)影響音頻質(zhì)量的因素和需要做哪些測(cè)試來(lái)評(píng)估一個(gè)音頻引擎有了一定的概念。有的朋友可能會(huì)說，這個(gè)評(píng)估工作看起來(lái)都好復(fù)雜，也需要不少資源投入。有沒有簡(jiǎn)單點(diǎn)的方法�。柯犝fWebRTC很火，可以直接拿來(lái)用嗎？
聲網(wǎng)Agora.io公眾號(hào)之前已經(jīng)有一篇關(guān)于WebRTC的優(yōu)缺點(diǎn)分析的文章。文中提到的缺乏服務(wù)器部署，缺乏多人支持等缺陷這里就不贅述了，這里來(lái)稍微深入的探討一下如果要將WebRTC音頻模塊商用，會(huì)遇到哪些問題。
1.移動(dòng)端的優(yōu)化不夠
WebRTC最初是為PC上的瀏覽器通信而設(shè)計(jì)的，所以相關(guān)的音頻算法，不管是從復(fù)雜度還是效果上都是以PC作為主要考量點(diǎn)的。雖然它也提供了像AECM這種專為mobile設(shè)計(jì)的低復(fù)雜度回聲消除算法，但是效果一直被詬病。在其官方論壇也能找不少關(guān)于該算法導(dǎo)致的回聲失真等問題的報(bào)告。而官方的答復(fù)是Won'tFix，理由是算法的已知缺陷。
2.對(duì)國(guó)產(chǎn)手機(jī)的“水土不服”
經(jīng)過之前的討論，我們已經(jīng)知道設(shè)備對(duì)音頻質(zhì)量有很大的影響。這種影響在五花八門的國(guó)產(chǎn)手機(jī)，特別是一些中低端機(jī)型上尤為明顯。如果讓W(xué)ebRTC音頻模塊直接在各種安卓機(jī)上跑的話，會(huì)遇到各種各樣的問題。也有不少朋友現(xiàn)在還沒有從這個(gè)坑里爬出來(lái)。這里不僅需要算法來(lái)適配補(bǔ)償聲學(xué)設(shè)計(jì)上的一些缺陷，也有不少是因?yàn)橐恍┲行∈謾C(jī)廠商沒有遵循相關(guān)的安卓音頻調(diào)用規(guī)范導(dǎo)致錄放音問題，這時(shí)候還需要做機(jī)型相關(guān)的底層適配。
3.非商業(yè)運(yùn)營(yíng)，無(wú)文檔無(wú)售后，遇到問題不好查
關(guān)于WebRTC音頻模塊的資料并不是很多，要了解每個(gè)算法模塊的細(xì)節(jié)需要花不少時(shí)間，而且需要對(duì)信號(hào)處理有比較扎實(shí)基礎(chǔ)的音頻算法工程師才行。很多時(shí)候我們所說的適配只是一個(gè)通用的說法，并不是已經(jīng)有很多開放出來(lái)的參數(shù)一個(gè)個(gè)試就能解決問題的。想要達(dá)到比較好的音頻體驗(yàn)，對(duì)算法的理解和投入是必須的，否則遇到音頻問題就會(huì)束手無(wú)策。雖然
WebRTC會(huì)通過自己的論壇和BugReport系統(tǒng)來(lái)收集一些用戶問題，但是要期望官方短期內(nèi)解決，還是需要多燒燒香的。
4.對(duì)復(fù)雜的應(yīng)用場(chǎng)景支持不夠
隨著應(yīng)用的多元化，我們開始需要在App里面定義多于一個(gè)的音頻行為。比如在游戲場(chǎng)景中需要播放游戲音效的同時(shí)進(jìn)行語(yǔ)音，比如在直播場(chǎng)景中主播需要把MP3等音樂文件和錄音混音處理。這些部分都不在WebRTC的考慮范圍之內(nèi)，需要自己團(tuán)隊(duì)來(lái)做開發(fā)。
結(jié)論
- 網(wǎng)絡(luò)，設(shè)備，物理環(huán)境都會(huì)影響音頻質(zhì)量，測(cè)試評(píng)估不要局限于單一環(huán)境。
- 全面的評(píng)估一個(gè)實(shí)時(shí)語(yǔ)音引擎需要科學(xué)的測(cè)試環(huán)境搭建和主客觀測(cè)試流程。
- 要自己實(shí)現(xiàn)實(shí)時(shí)語(yǔ)音通話功能需要對(duì)音頻有深入的研究和理解，不要輕信集成開源項(xiàng)目可以一勞永逸。
- 如果沒有足夠的開發(fā)資源和時(shí)間成本來(lái)自研實(shí)時(shí)語(yǔ)音引擎，盡量選擇對(duì)音頻有理解、有售后，靠譜的供應(yīng)商。
[本文作者]
陳若非聲網(wǎng)Agora.io資深音頻技術(shù)專家
負(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ā)部門，及為IEEE權(quán)威語(yǔ)音期刊和會(huì)議擔(dān)任評(píng)審工作。
相關(guān)閱讀：
- ·開發(fā)一個(gè)實(shí)時(shí)音視頻通信系統(tǒng)，你需要什么技術(shù)儲(chǔ)備？2016-06-14 10:32:33
- ·HTTPS和HTTP有什么區(qū)別，到底安全在哪里？2016-06-03 10:29:50
- ·從聲網(wǎng)Agora.io的實(shí)時(shí)云生意看中國(guó)SaaS2的未來(lái)2016-04-18 14:18:26
- ·技術(shù)創(chuàng)業(yè)者趙斌：幫助全球化App實(shí)現(xiàn)全球溝通2016-04-13 09:47:59
- ·聲網(wǎng)Agora：解決全球“移動(dòng)端到端”實(shí)時(shí)通信的挑戰(zhàn)2016-01-15 14:06:44
