在智能終端設(shè)備不斷更新?lián)Q代怨喘，移動通信基礎(chǔ)設(shè)施不斷升級的大環(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)肉拓，越來越多的廠商開始意識到自己的應(yīng)用中需要這種最原始自然的溝通方式，而想在短期內(nèi)在自己的應(yīng)用中嵌入多人音視頻通話功能成也變成了可能棚赔。
為了追求更好的用戶體驗(yàn)帝簇，大家也逐漸的從原來出聲就行出圖就行的舊觀念，逐漸轉(zhuǎn)化到了對音視頻質(zhì)量有著更高的要求和期待靠益。但是音頻的問題對于一般開發(fā)者來說比較神秘丧肴，很多朋友不太清楚如何全面的評估第三方的音頻引擎，也有不少朋友踩過很多有苦說不出的坑胧后。其中比較典型有幾種聲音：
-我們花了好多錢買了一套基于硬件的解決方案芋浮，開始用的還行，怎么現(xiàn)在越來越卡了壳快？
-我們評估了個引擎纸巷，自己內(nèi)網(wǎng)測試的時候感覺聲音很流暢，延時很小眶痰。為什么上線了很多用戶說又卡又延時傲鲋肌？
-我們用WebRTC做了一套方案竖伯，iPhone上還好存哲，但是為什么在安卓的機(jī)器上老是有回聲啊七婴？
-為什么我昨天用的還好好的祟偷，今天換了個手機(jī)/地方/網(wǎng)絡(luò)打效果差好多啊打厘？
要回答這些問題修肠，我們首先需要搞清楚到底哪些因素會影響對音頻質(zhì)量的評估。然后我們再來看需要做哪些測試才能比較全面的評估一個音頻引擎户盯。最后我們討論一下大家比較關(guān)心的WebRTC框架中的音頻模塊如何嵌施，是否適合商用饲化？
影響音頻質(zhì)量和穩(wěn)定性的因素到底有哪些呢？
1.網(wǎng)絡(luò)（丟包 延時?抖動）
網(wǎng)絡(luò)對音頻質(zhì)量的影響是非常直觀的艰管，如果承載音頻信息的語音包在網(wǎng)絡(luò)傳輸?shù)倪^程中丟失滓侍，晚到，或者不均勻的到牲芋，就會造成我們常說的丟包撩笆，延時和抖動。
從主觀聽感上造成聲音的卡頓和滯后缸浦，嚴(yán)重影響通話的質(zhì)量和可懂度夕冲。在公共互聯(lián)網(wǎng)上的，特別是在遠(yuǎn)距離通信的情況下裂逐，如果缺乏足夠的網(wǎng)絡(luò)部署和音頻的丟包對抗技術(shù)歹鱼，這種情況就會變得尤為明顯。如果是在內(nèi)網(wǎng)環(huán)境卜高，兩人通話的場景下弥姻，聲音可以通過點(diǎn)對點(diǎn)（P2P）的連接互相傳輸，很多網(wǎng)絡(luò)問題容易被單一的測試環(huán)境忽略了掺涛。
這也是為什么有些同學(xué)在自己的公司內(nèi)網(wǎng)測試時候感覺延時小聲音流暢庭敦，跑到真實(shí)環(huán)境下就經(jīng)常遇到各種各樣的質(zhì)量問題。
另外值得一提的是薪缆，除了在傳輸層引起的丟包抖動秧廉，最后一公里(Last Mile)的問題（路由器，移動數(shù)據(jù)網(wǎng)絡(luò)等）也會引起丟包抖動拣帽，所以有時候有的同學(xué)說我們家20M的帶寬疼电，怎么用起來還是卡頓。其實(shí)有時候路由器反而是產(chǎn)生問題的根源减拭。
2.設(shè)備?（聲學(xué)設(shè)計蔽豺，計算能力）
設(shè)備對于音頻質(zhì)量的影響是相對隱性的，但是往往會起著決定性的作用拧粪。比如iPhone就有著比較好的聲學(xué)設(shè)計修陡。麥克風(fēng)和揚(yáng)聲器之間的耦合程度較小，這樣你說話經(jīng)揚(yáng)聲器播放產(chǎn)生的回聲在被麥克風(fēng)收錄時候已經(jīng)有了很大程度的衰減既们，對回聲消除模塊來說也是一個利好濒析。另外它有三個麥克風(fēng)正什，位于設(shè)備底部的麥克風(fēng)主要收取說話人的聲音啥纸，位于背部的麥克風(fēng)用來拾取背景噪聲，給主麥克風(fēng)做參考婴氮，從而更好對人聲做降噪處理斯棒，讓對方聽得更清楚盾致。另外位于聽筒附近還有一個麥克風(fēng)用來感知聽筒附近的噪聲，從而生成一個反相位的波從聽筒里播放出來抵消這部分噪聲荣暮，讓你聽對方也可以聽的更清楚庭惜。
而設(shè)備的問題在安卓機(jī)上就非常碎片化，我想所有和安卓打過交道的開發(fā)者都沒少聽過適配這兩字穗酥。由于每個設(shè)備揚(yáng)聲器和麥克風(fēng)的屬性都不盡相同护赊，特別是在一些中低端機(jī)型上有些手機(jī)的聲學(xué)設(shè)計是非常不合理的（嚴(yán)重的麥克風(fēng)揚(yáng)聲器耦合，非線性失真砾跃，麥克風(fēng)底噪等）骏啰，會使得一些通用的音頻算法（回聲消除，降噪）無法正常工作抽高。這也回答了我們之前的問題判耕，為什么有些同學(xué)測的iPhone覺得不錯，但是到一些中低端的安卓機(jī)器上就問題百出翘骂。這類問題無論網(wǎng)絡(luò)好壞都會產(chǎn)生壁熄，這時候就必須有音頻引擎的算法模塊來做對應(yīng)的算法適應(yīng)和適配了。除此之外碳竟，在手機(jī)這類非實(shí)時操作系統(tǒng)上草丧，計算資源的搶占，錄放音的調(diào)度問題都會對音頻算法帶來很大的挑戰(zhàn)瞭亮。要解決這些問題就必須投入大量的資源去研發(fā)和調(diào)試方仿，而解決這類問題的技術(shù)門檻一般都是很高的。
3.物理環(huán)境?(密閉環(huán)境统翩，噪聲, 嘯叫等)
物理環(huán)境對音頻的影響更不容易被察覺仙蚜，但是它在很多情況下會干擾到音頻引擎的正常工作，從而對用戶的最終聽感產(chǎn)生負(fù)面影響厂汗。熟悉音頻算法的朋友都知道委粉，我們在做回聲消除的時候，需要實(shí)時估計出當(dāng)前物理環(huán)境的脈沖響應(yīng)(Impulse response)娶桦，才能將它和參考信號(Reference signal)卷積贾节，從而初步估算出麥克風(fēng)收到的回聲信號。假設(shè)我們現(xiàn)在身處一個密閉的會議室衷畦，揚(yáng)聲器播放出來的回聲部分在被麥克風(fēng)收錄時候就會摻入很多物理環(huán)境反射路徑帶來的分量栗涂，這個時候就要考察自適應(yīng)濾波器是否有足夠的能力來覆蓋這種場景了。如果音頻引擎做得不好祈争，就會導(dǎo)致我們平時遇到的一些奇怪現(xiàn)象斤程，比如為什么我剛才聽對方好好的，他換了個小會議繼續(xù)開會我就很多奇怪的雜音呢菩混？而事實(shí)上忿墅，影響脈沖響應(yīng)的因素遠(yuǎn)不止這些扁藕，甚至有研究發(fā)現(xiàn)每一度溫度的變化可能會導(dǎo)致40dB脈沖響應(yīng)的變化。
另外還有很多物理環(huán)境會對音頻質(zhì)量造成影響疚脐。比如近場時候的尖銳雜音（嘯叫）亿柑，是由于設(shè)備A的麥克風(fēng)會直接收錄到設(shè)備B的揚(yáng)聲器播放的聲音，然后又會傳回設(shè)備B播放出來棍弄，形成了一個正反饋回環(huán)導(dǎo)致的望薄。只要分開一定距離通話或者靜音掉其中一方就會消失。更直觀的例子比如本地身處嘈雜的環(huán)境下的聽對方會更困難呼畸，對方聽自己也會有受到噪聲的干擾式矫。再比如剛才說的密閉環(huán)境下，本身想保留的語音信號也會受到反射路徑的影響役耕，造成平時所說的混響(Reverb), 會讓對方聽到一些失真采转。
從上文的討論中我們可以看到，其實(shí)網(wǎng)絡(luò)瞬痘，設(shè)備和物理環(huán)境都會對音頻質(zhì)量造成很大的影響故慈，而且這種影響很多時候并非很直觀的可以察覺到。如果沒有科學(xué)的評估和定量的分析框全，很難通過一兩次測試來下比較全面和準(zhǔn)確的結(jié)論察绷。那么我們很自然的會問，我們需要怎樣來定量和全面的評估一個音頻引擎呢津辩？要做哪些測試才能覆蓋到盡量多的真是使用場景拆撼，同時又能盡可能的排除各種隨機(jī)的影響因素呢？那么下面這章我就來討論下這個問題喘沿。
要全面的評估一個第三方音頻引擎需要做哪些測試闸度？
1.客觀測試
我們想要定量的分析一個音頻引擎的優(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è)計的消聲室。我們需要可重復(fù)又高保真的發(fā)聲和收音裝置來覆蓋人的正常說話和聽力動態(tài)范圍错敢，所以需要人工耳和人工嘴翰灾。另外，為了覆蓋更多的真實(shí)場景，我們還需要網(wǎng)損設(shè)備來模擬和控制丟包预侯，需要近似真實(shí)環(huán)境的沉浸式噪音場景，我們需要在人工頭的四周布置高保真的音箱來制造噪聲聲場峰锁。
要執(zhí)行符合3GPP萎馅，ETSI等通信標(biāo)準(zhǔn)的客觀測試，我們需要搭建了類似下圖的測試環(huán)境虹蒋。以Head Acoustic的ACQUA系統(tǒng)為例糜芳，我們需要：
-將被測設(shè)備(DUT)置于消聲室內(nèi)，根據(jù)聽筒魄衅，耳機(jī)和外放模式對應(yīng)的標(biāo)準(zhǔn)距離和方法固定被測設(shè)備峭竣。
-參考設(shè)備(RD)放在消聲室外，通過Line-in線從測量前端(MFE)輸入標(biāo)準(zhǔn)的語音序列晃虫。
-做發(fā)送端的測量時皆撩，DUT接收到人工嘴的語音信號，經(jīng)過對應(yīng)的音頻模塊和網(wǎng)絡(luò)傳輸處理哲银，由消聲室外的RD收到解碼并送入MFE計算得分扛吞。
-做接收端的測量時，參考信號由MFE灌入RD荆责，經(jīng)過網(wǎng)絡(luò)傳輸被DUT收到解碼播放滥比，人工耳記錄下從DUT播放出來的聲音與參考信號比較計算得分。
-網(wǎng)損模擬裝置控制在發(fā)送端或者接收端加入不同類型的丟包做院，延時和抖動盲泛，來測量不利網(wǎng)絡(luò)環(huán)境下的引擎表現(xiàn)
-背景噪聲模擬裝置在消聲室環(huán)境中制造不同信噪比和噪聲類型的環(huán)境噪聲，測試音頻模塊的降噪效果键耕。
當(dāng)我們搭建好了實(shí)驗(yàn)室的環(huán)境寺滚，根據(jù)3GPP的標(biāo)準(zhǔn)，我們可以通過這套環(huán)境來定量的測量到一些端到端的音頻指標(biāo)了屈雄。同樣以ACQUA為例玛迄，我們可以測量但不限于：
-End-to-End Voice Delay（ms）：端到端延時，記錄從RD到DUT的端到端的語音延時棚亩，涵蓋設(shè)備和網(wǎng)絡(luò)的延時蓖议。
-Echo Attenuation（dB）：回聲抑制，測量回聲被抑制了多少讥蟆，單位是分貝勒虾，一般>60dB的數(shù)值回聲就不太容易被感知到了。
-POLQA： ITU較新的評估語音質(zhì)量的指標(biāo)瘸彤，是以前PESQ的升級版修然，可以測量32KHz的采樣率的語音。一般都通俗的把這類語音質(zhì)量的評分稱為MOS分，1-5分越高說明語音質(zhì)量越好愕宋。
-3QUEST： 同樣是類似MOS分的語音質(zhì)量測量玻靡，但是專門在噪聲環(huán)境下進(jìn)行，噪聲聲場需要有嚴(yán)格規(guī)定中贝，噪聲序列還需要參考相關(guān)標(biāo)準(zhǔn)囤捻。
-Loudness Rating (dB)：響度評分，測量人工耳可以聲壓級(SPL), 一般在[-20,20]范圍內(nèi)比較理想邻寿。
-Idle Channel Noise (dB)：空閑信道噪聲蝎土，測量在沒有語音活躍的狀態(tài)下噪聲的舒適度。這個值一般不高于-50dB
-Frequency Response (dB): 頻響, 在相關(guān)標(biāo)準(zhǔn)中有頻響曲線的掩蔽區(qū)間绣否，測量分對應(yīng)的是真實(shí)頻響高于掩蔽區(qū)間的分貝數(shù)誊涯，所以越高越好。
-Signal-to-Distortion ratio (dB)：信號失真比蒜撮，在MFE記錄下語音信號和失真直接的比值暴构，數(shù)值越高說明語音保真度越高。
-Double Talk (dB)：雙講段磨，記錄下語音在近端遠(yuǎn)端同時說話的時候的抑制情況榔至，分?jǐn)?shù)越低亏娜，說明雙講透明度越高葫辐，也就是語音的保留度更好梅肤。
客觀測試的一個重要優(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)是個很大的制約了晶丘。更重要的是，客觀測試可以暴露一些明顯的問題唐含，但是很難覆蓋到一些細(xì)節(jié)和定位到問題的根源浅浮。 所以無論是出于成本的考慮還是更細(xì)節(jié)的音頻分析，我們都需要有合理的主觀測試來彌補(bǔ)客觀測試的一些問題捷枯。
2.主觀測試
在業(yè)界滚秩，音頻主觀測試并沒有可以統(tǒng)一遵循的標(biāo)準(zhǔn)。雖然ITU對音頻主觀測試有一些建議和指引淮捆，但是每個測試都有自身的側(cè)重點(diǎn)設(shè)計和執(zhí)行也不盡相同郁油。
一般比較常用的做法是請足夠多的人來采集有統(tǒng)計意義的樣本本股，然后對測試人員做一定的聽音培訓(xùn)。最后根據(jù)信號失真度桐腌，背景侵入度拄显，和總體質(zhì)量等方面來對音頻通話打分。
這種方法主要用來比較不同引擎之間的總體主觀感受案站，如果需要更細(xì)節(jié)的發(fā)現(xiàn)和比較問題躬审，還是需要跟針對性的測試。
主觀測試相對來比較靈活嚼吞，可以不必限定在消聲室中進(jìn)行。但是為了盡量避免我們之前的提到的設(shè)備網(wǎng)絡(luò)環(huán)境的不確定因素蹬碧，測試人員和被測設(shè)備需要分別放置于兩個音源隔離的房間舱禽。網(wǎng)損的部分，可以使用Linux的TC NetEM模塊模擬恩沽，如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ì)量狼电，然后慢慢增加丟包率來測試一個引擎抗丟包的邊界。在tc的隨機(jī)丟包模型下弦蹂，聲網(wǎng)Agora.io的抗丟包能力一般在70%左右肩碟，這部分和一般的音頻引擎還是有比較明顯的差異。另外在細(xì)節(jié)的音頻模塊方面也需要很多針對性的測試凸椿，比如回聲消除削祈，降噪，增益控制脑漫，近場嘯叫髓抑，盲源分離等模塊都可以有非常詳細(xì)的細(xì)節(jié)指標(biāo)可以跟蹤。這里就借用聲網(wǎng)Agora Video Call和某些競品的對比測試報告优幸，來舉例說明下如何針對不同的算法模塊做一些定量分析启昧。對其他模塊有興趣歡迎聯(lián)系我們討論，這里就不一一展開了劈伴。
下圖（a）和（b）比較了某競品和聲網(wǎng)SDK在降噪（NS）方面的表現(xiàn)密末。這里用的是NOISEX-92語料庫中的Voice Babble握爷，混音的信噪比是5dB。 通過錄音和定量分析严里，我們可以看到在算法的收斂時間新啼，降噪后的殘留噪聲，和有語音時候的信噪比方面刹碾，聲網(wǎng)的音頻引擎效果有明顯的優(yōu)勢燥撞。
下圖（c）和（d）比較了某競品和聲網(wǎng)SDK在自動增益控制（AGC）方面的表現(xiàn)。在會議場景中這個參數(shù)會特別重要迷帜。因?yàn)楹苡锌赡艽蠹視x通話的設(shè)備有一定的距離說話物舒，如果這時候不經(jīng)過特殊的增益提高，對方會很難聽清一些參會者的聲音戏锹。從圖中分析后可以發(fā)現(xiàn)冠胯，如果兩邊大家都貼近話筒的時候，錄音的大家差異是不明顯的锦针。但是當(dāng)你測試離麥克風(fēng)有1米甚至2米的情況下荠察，有些競品的聲音就會變的很小，而有正確的增益控制的引擎就能讓你對音量均衡的聲音奈搜。
WebRTC的音頻引擎怎么樣悉盆？直接拿過來用可以嗎？
到這里馋吗，大家應(yīng)該對影響音頻質(zhì)量的因素和需要做哪些測試來評估一個音頻引擎有了一定的概念焕盟。有的朋友可能會說，這個評估工作看起來都好復(fù)雜宏粤，也需要不少資源投入京髓。有沒有簡單點(diǎn)的方法啊商架？聽說WebRTC很火堰怨，可以直接拿來用嗎？
聲網(wǎng)公眾號之前已經(jīng)有一篇關(guān)于WebRTC的優(yōu)缺點(diǎn)分析的文章蛇摸，有興趣的同學(xué)可以找出來看一下备图。那篇文章中提到的缺乏服務(wù)器部署，缺乏多人支持等缺陷這里就不贅述了赶袄，這里來稍微深入的探討一下如果要用WebRTC音頻模塊來商用會遇到哪些問題揽涮。
-移動端的優(yōu)化不夠
WebRTC最初是為PC上的瀏覽器通信而設(shè)計的，所以相關(guān)的音頻算法饿肺，不管是從復(fù)雜度還是效果上都是以PC作為主要考量點(diǎn)的蒋困。雖然它也提供了像AECM這種專為mobile設(shè)計的低復(fù)雜度回聲消除算法，但是效果一直被詬病敬辣。在其官方論壇也能找不少關(guān)于該算法導(dǎo)致的回聲失真等問題的報告雪标。而官方的答復(fù)是Won’t Fix, 理由是算法的已知缺陷零院。
-對國產(chǎn)手機(jī)的“水土不服”
經(jīng)過之前的討論，我們已經(jīng)知道設(shè)備對音頻質(zhì)量有很大的影響村刨。這種影響在五花八門的國產(chǎn)手機(jī)告抄，特別是一些中低端機(jī)型上尤為明顯。如果讓W(xué)ebRTC音頻模塊直接在各種安卓機(jī)上跑的話嵌牺，會遇到各種各樣的問題打洼。也有不少朋友現(xiàn)在還沒有從這個坑里爬出來。這里不僅需要算法來適配補(bǔ)償聲學(xué)設(shè)計上的一些缺陷逆粹，也有不少是因?yàn)橐恍┲行∈謾C(jī)廠商沒有遵循相關(guān)的安卓音頻調(diào)用規(guī)范導(dǎo)致錄放音問題募疮，這時候還需要做機(jī)型相關(guān)的底層適配。
-非商業(yè)運(yùn)營僻弹，無文檔無售后阿浓，遇到問題不好查
關(guān)于WebRTC音頻模塊的資料并不是很多，要了解每個算法模塊的細(xì)節(jié)需要花不少時間奢方，而且需要對信號處理有比較扎實(shí)基礎(chǔ)的音頻算法工程師才行搔扁。很多時候我們所說的適配只是一個通用的說法爸舒，并不是已經(jīng)有很多開放出來的參數(shù)一個個試就能解決問題的蟋字。想要達(dá)到比較好的音頻體驗(yàn)，對算法的理解和投入是必須的扭勉，否則遇到音頻問題就會束手無策鹊奖。雖然
WebRTC會通過自己的論壇和Bug Report系統(tǒng)來收集一些用戶問題， 但是要期望官方短期內(nèi)解決還是需要多燒燒香的涂炎。
-對復(fù)雜的應(yīng)用場景支持不夠
隨著應(yīng)用的多元化忠聚，我們開始需要在App里面定義多于一個的音頻行為。比如在游戲場景中需要播放游戲音效的同時進(jìn)行語音唱捣，比如在直播場景中主播需要把MP3等音樂文件和錄音混音處理两蟀。這些部分都不在WebRTC的考慮范圍之內(nèi)，需要自己團(tuán)隊(duì)來做開發(fā)震缭。
結(jié)論
網(wǎng)絡(luò)赂毯，設(shè)備，物理環(huán)境都會影響音頻質(zhì)量拣宰，測試評估不要局限于單一環(huán)境党涕。
全面的評估一個實(shí)時語音引擎需要科學(xué)的測試環(huán)境搭建和主客觀測試流程。
要自己實(shí)現(xiàn)實(shí)時語音通話功能需要對音頻有深入的研究和理解巡社，不要輕信集成開源項(xiàng)目可以一勞永逸膛堤。
如果沒有足夠的開發(fā)資源和時間成本來自研實(shí)時語音引擎，盡量選擇對音頻有理解晌该，有售后肥荔，靠譜的供應(yīng)商绿渣。
【本文作者】
陳若非 ?聲網(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)威語音期刊和會議擔(dān)任評審工作踏志。
【參考文獻(xiàn)】
[1] ITU-TP.863,?“Perceptual objective listening quality assessment (POLQA)”https://www.itu.int/rec/T-REC-P.863
[2] ETSI EG 202 39603, “Speech Processing Transmission and Quality Aspects (STQ);
Speech Quality performance in the presence of background noise Part 3: Background noise transmission - Objective test methods”http://www.etsi.org/deliver/etsi_eg/202300_202399/20239603/01.02.01_50/eg_20239603v010201m.pdf
[3] ETSI TS 103 106,“Speech and multimedia Transmission Quality (STQ);
Speech quality performance in the presence of background noise: Background noise transmission for mobile terminals-objective test methods”
http://www.etsi.org/deliver/etsi_ts/103100_103199/103106/01.01.01_60/ts_103106v010101p.pdf
[4] ETSI ES 202 396-1,“Speech and multimedia Transmission Quality (STQ);
Speech quality performance in the presence of background noise Part 1: Background noise simulation technique and background noise database”
http://www.etsi.org/deliver/etsi_es/202300_202399/20239601/01.04.00_50/es_20239601v010400m.pdf
[5] ITU-TP.835,“Subjective test methodology for evaluating speech communication systems that include noise suppression algorithm”
https://www.itu.int/rec/T-REC-P.835
[6] 3GPP TS 26.131 / ETSI TS 126 131,“Universal Mobile Telecommunications System (UMTS), LTE, Terminal acoustic characteristics for telephony, Requirements”
http://www.etsi.org/deliver/etsi_ts/126100_126199/126131/12.02.00_60/ts_126131v120200p.pdf
[7] 3GPP TS 26.132 / ETSI TS 126 132,“Universal Mobile Telecommunications System (UMTS), LTE, Speech and video telephony terminal acoustic test specification”
http://www.etsi.org/deliver/etsi_TS/126100_126199/126132/11.00.00_60/ts_126132v110000p.pdf
[8] 3GPP TS 51.010-1 / ETSI TS 151 010-1,“Digital cellular telecommunications system (Phase 2+); Mobile Station (MS) conformance specification; Part 1: Conformance specification”
http://www.etsi.org/deliver/etsi_TS/151000_151099/15101001/10.03.00_60/ts_15101001v100300p.pdf
