前言
RTC（實時音視訊通訊）技術的快速發展，助力了直播、短視訊等互動娛樂形式的普及；在全球疫情持續蔓延的態勢下，雲會議需求呈現爆發式增長，進一步推動了 RTC 行業的快速發展。為了給客戶提供穩定可靠的服務，網路系統方面需要不斷提升頻道連通率，降低會議過程中的斷流率，增強抗弱網能力；視訊方面需要提升視訊清晰度，降低視訊卡頓率等，音訊方面在追求端到端 MOS 的同時，也要重點關注音訊 3A 演算法的效果，這些都是各廠家必須修煉的 “內功”，也是最終沉澱下來的核心競爭力。本文將重點闡述硬體裝置採集的音訊質量對 RTC 端到端音訊體驗的重要性。
採集質量不佳，會有什麼影響？
在 RTC 架構中，端到端的音訊訊號處理流程大致如下圖，上行分別經過了音訊訊號的採集，音訊 3A（AEC: 回聲消除、ANS: 自適應降噪和 AGC: 自動增益控制）和編碼；下行分別經過丟包恢復，解碼，混音和播放。
端到端的音訊訊號處理流程
不難看出，音訊訊號經過模數轉換，再經過裝置整合的音訊訊號處理晶片，最後才傳遞給 RTC SDK。由於硬體廠商的不同，音訊採集解決方案參差不齊，因此採集到的音訊質量的好壞直接影響著 3A 演算法拿到的生產資料的可用性，同時也決定這終端使用者接收到音訊訊號質量的上限。根據實際工作中遇到的音訊問題，因為裝置採集引起的問題基本可以歸納為如下幾類：
舉幾個例子：
（1）採集異常
採集異常主要體現在頻譜 “模糊”，嚴重的會導致無法聽懂語義，影響正常交流。如下語譜圖。
另外，採集異常後，播放的訊號被麥克風採集後也會表現出異常，從而引起嚴重的非線性失真，影響回聲消除效果，如下圖。
(2) 採集抖動
常見的就是採集丟資料，聽感上會聽到有很多高頻噪點（下圖為上圖中噪點放大後的區域性圖），嚴重的會影響 AEC 演算法中對延時估計準確性和遠近端非因果問題，嚴重的會導致漏回聲。
（3）爆音和音量小問題
採集爆音問題主要發生在 PC，也是 PC 端裝置最應該避免的問題，影響較大，除了截頂導致的頻譜失真之外，嚴重的非線性失真會影響回聲消除效果。爆音問題需要 AGC 演算法通過自適應調節 PC 端模擬增益以及麥克風加強解決。
（4）頻譜缺失
頻譜缺失主要是硬體回撥的音訊取樣率與實際的頻譜分佈不一致，即使編碼器給到很高的編碼位元速率，聽感上也沒有高音質的效果，如下圖，採集訊號取樣率為 48kHz，但是頻譜上限卻只有 8k。
改善採集音質，硬體層面我們能做什麼？
具備 RTC 能力的硬體裝置早已滲透我們生活的方方面面，常見的如移動端手機和 PC，現在甚至連兒童電話手錶，天貓精靈以及各種高階的指紋密碼鎖等裝置都支援了 RTC。然而，裝置的多樣性直接決定這採集能力的差異性，拋開聲學元器件設計差異這一因素，就 Android 端而言，晶片和軟體系統的差異使得同一品牌的手機，也沒辦法用同一種配置適配所有型號的手機。
另外，現在絕大多數的移動端裝置都自帶硬體音訊訊號處理（後稱硬體 3A）能力，不同晶片效果方面也是千差萬別的同時，更嚴重的是經過硬體處理的音訊訊號頻譜往往會有缺失，如開啟硬體 3A 後回撥到 RTC SDK 的音訊訊號頻譜上限僅支援到 8k，相當於 16kHz 取樣的音訊訊號，尤其在娛樂方面根本無法滿足我們對高音質的追求。因此，做好硬體層的適配工作，是保障 RTC 高質量音訊體驗的基礎。
Android 端
（1）需要搞清楚 javaaudioclass 和 opensles 這兩種模式的差異，以及各自需要適配的引數，掌握關閉硬體 3A 的配置。
（2）採集抖動或音訊音量異常，可以試試更改請求的取樣率，通常設定的 48k 取樣不會適用於所有的 android 裝置。
Windows 端
（1）當前很多 Windows 裝置會在螢幕頂端內建麥克風陣列，提供音訊增強功能，開啟方式如下圖。這個功能預設螢幕正前方夾角區域為拾音區域，通過麥克風陣列技術可以有效的增強拾音區域內發言人語音，“隔離” 拾音區域以外的 “噪聲”，其主要的弊端就在於開啟此功能後僅支援 8k 頻譜，且各廠家增強演算法存在差異，效果也參差不齊。因此，軟體需要具備能夠 bypass 硬體自帶音訊增強功能的能力，為高音質做保障。
Windows 裝置自帶的雙麥陣列（圖片來源於網路）
音訊設定中的增強功能開關
開啟音訊增強後，帶來的頻譜缺失
（2）音量方面，PC 端裝置都支援模擬增益調節，大多數帶有陣列的 Windows 裝置都有額外的麥克風加強（如下圖）。軟體演算法層面（3A 中的 AGC）需要具備自適應調節他們的能力，保障音訊採集音量的平穩以控制採集底噪水平。初值設定或自適應調節不當都會導致音量小和爆音等問題，嚴重的會影響回聲消除和降噪的效果，帶來影響可用性的風險。
模擬增益與麥克風加強
蘋果裝置
（1）ios 端適配工作較少，需要熟悉關閉硬體 3A 的配置，因為 ios 裝置自帶的硬體 3A 頻譜也只能支援到 10k-12k。
（2）Mac 筆記本裝置比較簡單，僅提供了模擬增益調節。但是有一點需要注意，RTC 在支援雙聲道播放時，由於麥克風會與某個揚聲器在同一側，導致播放音訊時附近的麥克風採集爆音問題，一般只能優化軟體 AEC 演算法解決。
總結
當 48k 高音質成了剛需，為了保障採集環節的高質量，一方面需要投入時間去掌握 Android 引數適配的規律，同時市面上出現的越來越多的定製化的 android 裝置（手錶，智慧音響等），也必不可少的需要先確定好配置引數；另一方面關閉硬體裝置自帶的音訊處理功能，啟用 RTC 自帶的純軟 3A 演算法也是一種趨勢，前提是要優化好軟體 3A 演算法整體效果以及控制好功耗，這也是客戶評測各廠家之間音訊體驗的必測項，也是各廠家的核心競爭力之一。
「視訊雲技術」你最值得關注的音視訊技術公眾號，每週推送來自阿里雲一線的實踐技術文章，在這裡與音視訊領域一流工程師交流切磋。公眾號後臺回覆【技術】可加入阿里雲視訊雲產品技術交流群，和業內大咖一起探討音視訊技術，獲取更多行業最新資訊。