導讀： 隨著 5G 網路的普及以及疫情帶來的影響，人們對實時音視訊技術的應用場景會越來越多，包括會議、連麥、音視訊通話、線上教育、遠端醫療等，這些實時互動場景對 RTC 音訊的質量提出了越來越高的要求。如何對 RTC 音訊的效果開展測試，通過構建客觀、標準、可重複的評價體系來保證好的音訊傳輸質量，也成為目前比較緊急和重要的課題。

文｜馬建立 網易雲信資深音視訊測試工程師 

理想的溝通模型

日常溝通中面對面的交流一般有比較好的效果，如果在一個安靜的實驗室內，減少環境的干擾和影響，會得到理想的溝通效果。我們再把這個模型抽象一下，大體可以看出有以下的特點：

環境安靜： NR15 的底噪，相當於在極其安靜的夜晚，人耳能不受到其他影響的干擾，集中注意力聽目標人聲。

適宜聽音的混響環境： 混響通常會影響聽音者的理解程度，混響越大，語音的拖尾越長，可懂度也就越低。比如在混響較大的演唱廳，對於樂器和歌聲來說，會有一定的美化效果，但是對於人的溝通交流是不利的。

語音清晰、自然： 講話者心理和生理都處在極佳的狀態，發音清楚，頻率均衡，語音流暢，語速適中。

聲音大小適中： 研究表明，音量對音質的影響是顯著的，在其他條件一致的情況下，音量越大，主觀聽感越好。講話者說話聲音洪亮，在一定程度上能提升聽音者的可懂度。

響應及時、溝通順暢： 在 RTC 的實時溝通中，延時也是一個非常重要的指標，一般來說，200ms 以內人的延時人的主觀感覺無明顯的障礙和遲滯感，200ms-400ms 能正常溝通，超過 400ms 就會有的遲滯感，更嚴重時會出現搶話的現象，直接影響通話的體驗。在面對面的溝通場景下，時延只有 3ms 左右。

RTC 音量鏈路

上圖是通過 RTC 實時溝通的兩個人，從圖上可以看出，講話者 A 開始說話，聲音經過空氣傳播、麥克風採集、A/D 轉換、增強處理（降噪、回聲消除、音量控制、去混響）、編碼、打包傳輸、接收端解碼、NetEQ、D/A 轉換到下行播放，然後 B 聽到聲音。這是單工狀態下的完整的聲音傳輸的路徑。

與理想的溝通模型相比，實際的 RTC 鏈路中存在多種型別的干擾和影響，比如環境影響、硬體影響、鏈路影響和網路影響，每個環節都有可能引入音訊質量的下降。這些影響綜合下來，會導致如下幾個方面的聲音的問題。

• 音量問題 ： 無聲、音量小、聲音大導致的削波、刺耳等、忽大忽小。
• 回聲類問題： 漏回聲、回聲殘留、語音損傷如壓制、剪下、斷續。
• 噪聲類問題： 噪聲殘留不平穩。
• 系統引入問題： 雜音、電流音、popo音。
• 狹義的音質問題： 語音模糊、語音失真、語音發悶、語音尖銳、機械音。
• 網路問題： 卡頓、斷續、快放、慢放、機械音。

主觀測試方法

最早的主觀測試以兩個人通話為主，A 和 B 建立起 RTC 的連結，通過分別或者同時講話，還原真實場景的使用者使用場景，主要關注的以下 3 個維度。

Listening Quality ： 聽音者的音質，是單工的使用場景，比如 A 在講話，B 聽到的聲音的質量，就是 Listening Quality，Listening Quality 描述了大部分情況下的語音質量，也是最基礎的部分，目前業界已有的客觀評價方法和手段基本上都是基於 Listening Quality。

Talking Quality ： 講話者的音質，是講話人自己聽到的聲音質量，與回聲、側音掩蔽、本地的環境都有一定的關係。

Conversation Quality ： 對話音質，除了包含 A/B 兩個人的 Listening Quality 和 Talking Quality，還跟雙工通話有關係，主要的影響因素有回聲雙講和端到端延時。

主觀測試關注的維度**

主觀測試要關注的點如上圖所示，分為音質、音色、音量、延時、回聲、降噪等幾個大的方面。

音色

音色又稱之為音品，是聽覺感到的聲音的特色，音色主要決定於聲音的頻譜。 在 RTC 的鏈路中，影響聲音的頻率響應主要是麥克風的頻率特性、中間處理如 EQ、高低通濾波、以及音量控制的演算法（DRC/AGC)、揚聲器/耳機得到頻響等。不同人的發聲頻率分佈也有差異， 一般來說男性聲音低頻多，聲音渾厚或者偏悶，女性或者小孩有更多的高頻成分，聲音明亮甚至有些尖銳。

音質： 音質分為 3 個維度，清晰度、流暢度和自然度。

• 清晰度在音訊領域也叫可懂度。 表示對語義內容的理解程度，影響可懂度的方面有很多，比如：語音中混入噪聲使得語音聽不清楚，導致可懂度下降；語音中有大混響，導致語音拖尾，聽不清楚。
• 流暢度表示語音的連續程度。 直接影響的因素有：網路環境差導致語音斷續、卡頓、丟字等；QoS 調整導致的聲音快放、慢放；回聲和降噪等演算法導致的語音損傷。
• 自然度表示與原始語音的相似程度。 影響自然度的典型問題有：演算法處理引入的失真；揚聲器的非線性失真；聲音放大過多造成的削波、過載等。

音量

對於 RTC 的 SDK 供應商來說，面臨的最大挑戰是裝置多樣性，不同的平臺（Mac、Windows、Android、iOS、Web），以及不同機型和不同的外接裝置，不同的機型或者裝置採集、播放音量差異大。音量控制的策略在於能夠保證不同平臺裝置之間的一致性， 保證使用者能夠聽到足夠大小的聲音，且不會顯性的帶來音質損傷和下降。

噪聲

降噪演算法的目的在於去除環境或者裝置引入的噪聲干擾，儘可能多的還原人聲，提升訊雜比。實際的降噪演算法在處理噪聲的過程中，都不可避免的、或多或少的損傷音質。因此評價降噪主要從兩個方面考慮: 

• 噪聲的抑制水平。 包括收斂時間、抑制力度、殘留平穩性等。
• 語音的損傷程度。 好的降噪演算法總是能夠在這兩者之間達到一個相對的平衡，既能有效的抑制噪聲，又沒有明顯的損傷語音。

回聲

回聲消除是 RTC 鏈路中比較重要的一個模組，目的是消除裝置的回聲，保證順暢的通話體驗。 評價回聲也主要從兩個點出發：

• 回聲的抑制力度。 回聲是否有殘留。
• 對近端語音的損傷情況。 在 RTC 的應用場景，回聲也與裝置、平臺、機型和外接裝置關係很大，因此回聲的測試需要覆蓋 TOP 機型。   

延時

網路傳輸中音訊對抗丟包的演算法如 FEC、RED、ARQ，以及對抗丟包的演算法如 Jitter Buffer 等，都會產生額外的延時，導致端到端的延時增大，對於實時溝通交流帶來負面的影響和體驗下降。尤其是對於一些低時延的場景來說，端到端延時是一個衡量弱網對抗效能的重要指標。

主觀測試的痛點**

目前 RTC 音訊的主流評價方式主要依靠主觀測試和聽音，這種方式對於人的專業能力要求比較高，而且效率比較低。主要有以下幾個方面的痛點：

• 可重複性差： 主觀測試很難保證兩次測試的一致，比如聲場環境的變化、說話人發音變化、音量大小變化、與裝置之間的距離差異等等，不可控因素太多，沒辦法得到準確的對比測試結果。
• 測試效率低： 主觀測試需要兩個人全程參與，長時間的測試無論聽音還是發聲，都會產生疲勞和懈怠感，且需要根據用例切換場景，測試效率非常低。
• 測試覆蓋率低： 因為效率的問題，實測只能覆蓋有限的場景和有限的鏈路組合，通常來說只能保證重點場景。且測試人員本身的聲音有侷限性，沒有辦法覆蓋更多種類的人聲。
• 主觀因素影響大： 聲音是很主觀的東西，同一段聲音在不同人的聽感不盡相同，單個人的測試結果有可能會導致結論有失偏頗。且人的發聲和聽音，與生理和心理的狀態有著極大的關係，同一個人在不同時間段會給出截然不同的判斷和結論。

針對以上的痛點問題，網易雲信目前在音訊效果的評價和測試上，打造了一套從實驗室構建、環境模擬、採集播放、評價方法端到端的客觀評價方法。

標準實驗室

上圖是網易雲信的聲學實驗室，主要的裝置和硬體配置如下所示：

• 頭肩模擬器： 內建嘴部模擬器和經過較準的耳部模擬器（符合 IEC 60318–4/ITU‐T Rec. P.57 Type 3.3 標準）的人體模型，可以真實再現普通成年人頭部和軀幹的聲學特性，進行精準的雙耳聲學訊號 採集和嘴部發聲。
• 4* 高保真音響： 構造均勻的散射聲場，線上模擬並回放不同場景和訊雜比的噪聲環境。
• 多路音效卡： 支援同時8入8出的聲音採集和播放，滿足多種音訊測試的場景設定。
• 4 路電訊號介面： 支援多人語音測試 和 回聲單雙講測試。

通過構建專業的音訊測試實驗室，滿足音訊自動化測試/競品分析評測/版本間基線效果快速對比測試的需求，獲得可重複的客觀測試結果，同時能夠滿足研發音訊演算法模擬和原型驗證的需求。還可以一人完成 3A 主觀測試：降噪、音質、回聲單雙講測試。目前 AI 演算法越來越多，資料是 AI 類演算法的關鍵，有了聲學實驗室和噪聲模擬系統，通過編寫自動化指令碼的方式，可以實現 AI 資料自動採集和標註，大大降低資料購買和標記成本。 目前雲信的聲學實驗室組網如上圖所示，實驗室的引入提升了開發和測試的專業度，主要有以下方面的應用：

• 自動化測試： 客觀的 3A 自動化測試，如回聲測試、噪聲測試，可模擬多人入會場景。
• AI 資料自動化採集： 開源的語音、目標噪聲分別通過人頭和噪聲回放系統播放，在目標端或者平臺上回錄，錄製的過程中可以打標籤，同時解決序列採集和標記的問題。
• 主觀測試： 定量的播放環境和安靜的聽音環境。
• 其它： 機型覆蓋測試、機型適配、演算法原型優化驗證。

客觀測試標準

實驗室主要是提供了客觀可重複的測試環境，硬體裝置支援自定義的採集和播放，除此之外，目前網易雲信的音訊實驗室還引入了客觀的測試標準，作為最終資料的評價方法。音訊測試標準按照不同維度有不同的劃分。

主觀/客觀

主觀是基於人類的主觀評價，客觀方法是用模型來計算和評估語音質量。典型的主觀評測標準如P.800,客觀的語音質量評測方法如 PESQ。

有參考/無參考

完全參考/無參考 (FR/NR) 描述所用測量演算法的型別。FR 演算法有兩個訊號：原始訊號和失真訊號。NR 演算法只需要一個失真訊號。典型的 FR 演算法是例如 PESQ。典型的 NR 測量是 P.563，NR 方法也常被稱為“單端”測試。

感知/非感知

通常，此類測量演算法會嘗試對人類感知進行建模。感知建模不僅用於質量的評估。其他著名的感知演算法例如使用感知模型的 MP3 或 AAC 用於壓縮音樂。非感知指標是一般的物理或技術指標，例如電平或訊雜比。

基於感知模型的客觀標準**

基於感知模型的客觀指標最經典也是應用最廣泛的是有源客觀語音質量測試標準 p.86x 系列，也是就常說的 PESQ/POLQA，是一種典型的有參考的語音評價標準， PESQ/POLQA 總的思路是：對原始訊號（參考訊號）和通過測試系統的訊號進行電平調整到標準聽覺電平，再用輸入濾波器模擬標準電話聽筒進行濾波。

對通過電平調整和濾波後的兩個訊號在時間上對準，並進行聽覺變換，這個變換包括對系統中線性濾波和增益變化的補償和均衡。兩個聽覺變換後的訊號之間的不同作為擾動（即差值），分析擾動曲面提取出兩個失真引數，在頻率和時間上累積起來，對映到對主觀平均意見分的預測值。POLQA 相對於 PESQ 做了大量精度的優化， 使得客觀測試結果與主觀測試結果的一致性更高，在語音評測方面有個非常廣泛的應用。

自動化測試

POLQA 自動化測試

網路測試中，為減少硬體採集播放和聲學鏈路的影響採用電訊號鏈路的測試。 傳送端和接受端的兩臺裝置使用 3.5mm 的音訊線與音效卡連線。此外，有一套 TC 系統來提供網損環境，被測試的兩臺裝置接入 TC 的 Router，通過指令碼控制兩端裝置的丟包、延時、抖動和頻寬。

如上圖所示，測試主機通過音效卡將訊號傳送給測試裝置 A，測試裝置經過本端的 RTC 音訊處理後，經過網路傳輸傳送到接收端裝置 B，在這個過程中，通過弱網系統實時新增不同型別和程度的網損。音效卡接收到測試裝置 B 的訊號，通過與原始訊號的比對和分析，來衡量 RTC 對於弱網對抗模組的效能。

• 支援 Android 端、iOS 端、Windows 端、Mac 端、Web 端的互通測試；
• 使用 TC 指令碼自動化控制網路環境；
• 使用 API 自動化控制入會、切換 profile、引數控制、離開會議；
• 自動化獲取測試過程中的位元速率、丟包、卡頓等打點資訊作為輔助標準；
• 一鍵執行，生成版本基線報告；

3A 客觀自動化

網易雲信目前基於實驗室搭建了端到端的 3A 自動化測試，架構框圖如上圖所示，主要分為用例管理層、API/UI 控制層、採集和播放、自動校準、分析與計算、資料和報告幾個大的模組。主要用於回聲、噪聲和音量控制的綜合評價，目前在版本基線測試、版本迭代對比、競品對比等測試環節中應用。

作者介紹**

馬建立，網易雲信資深音視訊測試工程師，網易雲信音視訊媒體實驗室核心成員，負責音訊測試質量體系建設和音視訊質量保障工作。