前言：近年來，音視頻會議產品提高着工做協同的效率，在線教育產品突破着傳統教育形式的種種限制，娛樂互動直播產品豐富着生活社交的多樣性，背後都離不開音視頻通訊技術的優化與創新，其中音頻信息內容傳遞的流暢性、完整性、可懂度直接決定着用戶之間的溝通質量。自 2011 年 WebRTC 開源以來，不管是其技術架構，仍是其中豐富的算法模塊都是值得咱們細細品味，音頻方面熟知的 3A 算法（AGC: Automatic gain control; ANS: Adaptive noise suppression; AEC: Acoustic echo cancellation）就是其中閃閃發光的明珠。本文章將結合實例全面解析 WebRTC AEC 的基本框架和基本原理，一塊兒探索回聲消除的基本原理，技術難點以及優化方向。算法
做者：珞神，阿里雲高級開發工程師，負責阿里雲 RTC 音頻研發緩存
回聲的造成
WebRTC 架構中上下行音頻信號處理流程如圖 1，音頻 3A 主要集中在上行的發送端對發送信號依次進行回聲消除、降噪以及音量均衡（這裏只討論 AEC 的處理流程，若是是 AECM 的處理流程 ANS 會前置），AGC 會做爲壓限器做用在接收端對即將播放的音頻信號進行限幅。網絡
那麼回聲是怎麼造成的呢？架構
如圖 2 所示，A、B 兩人在通訊的過程當中，咱們有以下定義：併發
- x(n): 遠端參考信號，即 A 端訂閱的 B 端音頻流，一般做爲參考信號；
- y(n): 回聲信號，即揚聲器播放信號 x(n) 後，被麥克風採集到的信號，此時通過房間混響以及麥克風採集的信號 y(n) 已經不能等同於信號 x(n) 了, 咱們記線性疊加的部分爲 y'(n), 非線性疊加的部分爲 y''(n), y(n) = y'(n) + y''(n)；
- s(n): 麥克風採集的近端說話人的語音信號，即咱們真正想提取併發送到遠端的信號；
- v(n)：環境噪音，這部分信號會在 ANS 中被削弱；
- d(n): 近端信號，即麥克風採集以後，3A 以前的原始信號，能夠表示爲：d(n) = s(n) + y(n) + v(n)；
- s'(n): 3A 以後的音頻信號，即準備通過編碼發送到對端的信號。
WebRTC 音頻引擎可以拿到的已知信號只有近端信號 d(n) 和遠端參考信號 x(n)。框架
若是信號通過 A 端音頻引擎獲得 s'(n) 信號中依然殘留信號 y(n)，那麼 B 端就能聽到本身回聲或殘留的尾音（回聲抑制不完全留下的殘留）。AEC 效果評估在實際狀況中能夠粗略分爲以下幾種狀況（專業人員可根據應用場景、設備以及單雙講進一步細分）：機器學習
回聲消除的本質
在解析 WebRTC AEC 架構以前，咱們須要瞭解回聲消除的本質是什麼。音視頻通話過程當中，聲音是傳達信息的主要途徑，所以從複雜的錄音信號中，經過信號處理的手段使得咱們要傳遞的信息：高保真、低延時、清晰可懂是一直以來追求的目標。在我看來，回聲消除，噪聲抑制和聲源分離同屬於語音加強的範疇，若是把噪聲理解爲廣義的噪聲三者之間的關係以下圖：ide
噪聲抑制須要準確估計出噪聲信號，其中平穩噪聲能夠經過語音檢測判別有話端與無話端的狀態來動態更新噪聲信號，進而參與降噪，經常使用的手段是基於譜減法(即在原始信號的基礎上減去估計出來的噪聲所佔的成分)的一系列改進方法，其效果依賴於對噪聲信號估計的準確性。對於非平穩噪聲，目前用的較多的就是基於遞歸神經網絡的深度學習方法，不少 Windows 設備上都內置了基於多麥克風陣列的降噪的算法。效果上，爲了保證音質，噪聲抑制容許噪聲殘留，只要比原始信號信噪比高，噪且聽覺上失真無感知便可。學習
單聲道的聲源分離技術起源於傳說中的雞尾酒會效應，是指人的一種聽力選擇能力，在這種狀況下，注意力集中在某一我的的談話之中而忽略背景中其餘的對話或噪音。該效應揭示了人類聽覺系統中使人驚奇的能力，即咱們能夠在噪聲中談話。科學家們一直在致力於用技術手段從單聲道錄音中分離出各類成分，一直以來的難點，隨着機器學習技術的應用，使得該技術慢慢變成了可能，可是較高的計算複雜度等緣由，距離 RTC 這種低延時系統中的商用仍是有一些距離。測試
噪聲抑制與聲源分離都是單源輸入，只須要近端採集信號便可，傲嬌的回聲消除須要同時輸入近端信號與遠端參考信號。有同窗會問已知了遠端參考信號，爲何不能用噪聲抑制方法處理呢，直接從頻域減掉遠端信號的頻譜不就能夠了嗎？
上圖中第一行爲近端信號 s(n)，已經混合了近端人聲和揚聲器播放出來的遠端信號，黃色框中已經標出對齊以後的遠端信號，其語音表達的內容一致，可是頻譜和幅度(明顯通過揚聲器放大以後聲音能量很高)均不一致，意思就是：參考的遠端信號與揚聲器播放出來的遠端信號已是「貌合神離」了，與降噪的方法相結合也是不錯的思路，可是直接套用降噪的方法顯然會形成回聲殘留與雙講部分嚴重的抑制。接下來，咱們來看看 WebRTC 科學家是怎麼作的吧。
信號處理流程
WebRTC AEC 算法包含了延時調整策略，線性回聲估計，非線性回聲抑制 3 個部分。回聲消除本質上更像是音源分離，咱們指望從混合的近端信號中消除不須要的遠端信號，保留近端人聲發送到遠端，可是 WebRTC 工程師們更傾向於將兩我的交流的過程理解爲一問一答的交替說話，存在遠近端同時連續說話的狀況並很少（即保單講輕雙講）。
所以只須要區分遠近端說話區域就能夠經過一些手段消除絕大多數遠端回聲，至於雙講恢復能力 WebRTC AEC 算法提供了 {kAecNlpConservative, kAecNlpModerate, kAecNlpAggressive} 3 個模式，由低到高依次表明不一樣的抑制程度，遠近端信號處理流程如圖 4：
NLMS 自適應算法（上圖中橙色部分）的運用旨在儘量地消除信號 d(n) 中的線性部分回聲，而殘留的非線性回聲信號會在非線性濾波（上圖中紫色部分）部分中被消除，這兩個模塊是 Webrtc AEC 的核心模塊。模塊先後依賴，現實場景中遠端信號 x(n) 由揚聲器播放出來在被麥克風採集的過程當中，同時包含了回聲 y(n) 與近端信號 x(n) 的線性疊加和非線性疊加：須要消除線性回聲的目的是爲了增大近端信號 X(ω) 與濾波結果 E(ω) 之間的差別，計算相干性時差別就越大（近端信號接近 1，而遠端信號部分越接近 0），更容易經過門限直接區分近端幀與遠端幀。非線性濾波部分中只須要根據檢測的幀類型，調節抑制係數，濾波消除回聲便可。下面咱們結合實例分析這套架構中的線性部分與非線性分。
線性濾波
線性回聲 y'(n) 能夠理解爲是遠端參考信號 x(n) 通過房間衝擊響應以後的結果，線性濾波的本質也就是在估計一組濾波器使得 y'(n) 儘量的等於 x(n)，經過統計濾波器組的最大幅值位置 index 找到與之對齊遠端信號幀，該幀數據會參與相干性計算等後續模塊。
須要注意的是，若是 index 在濾波器階數兩端瘋狂試探，只能說明當前給到線性部分的遠近端延時較小或過大，此時濾波器效果是不穩定的，須要藉助固定延時調整或大延時調整使 index 處於一個比較理想的位置。線性部分算法是能夠看做是一個固定步長的 NLMS 算法，具體細節你們能夠結合源碼走讀，本節重點講解線型濾波在整個框架中的做用。
從我的理解來看，線性部分的目的就是最大程度的消除線性回聲，爲遠近端幀判別的時候，最大程度地保證了信號之間的相干值( 0~1 之間，值越大相干性越大)的可靠性。
咱們記消除線性回聲以後的信號爲估計的回聲信號 e(n)，e(n) = s(n) + y''(n) + v(n)，其中 y''(n) 爲非線性回聲信號，記 y'(n) 爲線性回聲，y(n) = y'(n) + y''(n)。相干性的計算 （Matlab代碼）：
% WebRtcAec_UpdateCoherenceSpectra →_→ UpdateCoherenceSpectra Sd = Sd * ptrGCoh(1) + abs(wined_fft_near) .* abs(wined_fft_near)*ptrGCoh(2); Se = Se * ptrGCoh(1) + abs(wined_fft_echo) .* abs(wined_fft_echo)*ptrGCoh(2); Sx = Sx * ptrGCoh(1) + max(abs(wined_fft_far) .* abs(wined_fft_far),ones(N+1,1)*MinFarendPSD)*ptrGCoh(2); Sde = Sde * ptrGCoh(1) + (wined_fft_near .* conj(wined_fft_echo)) *ptrGCoh(2); Sxd = Sxd * ptrGCoh(1) + (wined_fft_near .* conj(wined_fft_far)) *ptrGCoh(2); % WebRtcAec_ComputeCoherence →_→ ComputeCoherence cohde = (abs(Sde).*abs(Sde))./(Sd.*Se + 1.0e-10); cohdx = (abs(Sxd).*abs(Sxd))./(Sx.*Sd + 1.0e-10);
兩個實驗
（1）計算近端信號 d(n) 與遠端參考信號 x(n) 的相關性 cohdx，理論上遠端回聲信號的相干性應該更接近 0（爲了方便後續對比，WebRTC 作了反向處理: 1 - cohdx），如圖 5(a)，第一行爲計算近端信號 d(n)，第二行爲遠端參考信號 x(n)，第三行爲兩者相干性曲線: 1 - cohdx，會發現回聲部分相干值有明顯起伏，最大值有0.7，近端部分總體接近 1.0，可是有持續波動，若是想經過一條固定的門限去區分遠近端幀，會存在不一樣程度的誤判，反映到聽感上就是回聲（遠端判斷成近端）或丟字（近端判斷爲遠端）。
圖 5 信號的相干性
（2）計算近端信號 d(n) 與估計的回聲信號 e(n) 的相干性，如圖 5(b)，第二行爲估計的回聲信號 e(n)，第三行爲兩者相干性 cohde，很明顯近端的部分幾乎所有逼近 1.0，WebRTC 用比較嚴格的門限（>=0.98）便可將區分絕大部分近端幀，且誤判的機率比較小，WebRTC 工程師設置如此嚴格的門限想必是寧肯犧牲一部分雙講效果，也不肯意接受回聲殘留。
從圖 5 能夠體會到，線性濾波以後能夠進一步凸顯遠端參考信號 x(n) 與估計的回聲信號 e(n) 的差別，從而提升遠近端幀狀態的判決的可靠性。
存在的問題與改進
理想狀況下，遠端信號從揚聲器播放出來沒有非線性失真，那麼 e(n) = s(n) + v(n)，但實際狀況下 e(n)與d(n) 很像，只是遠端區域有一些幅度上的變化，說明 WebRTC AEC 線性部分在這個 case 中表現不佳，如圖 6(a) 從頻譜看低頻段明顯削弱，但中高頻部分幾乎沒變。而利用變步長的雙濾波器結構的結果會很是明顯，如圖 6(b) 所示不管是時域波形和頻譜與近端信號 x(n) 都有很大差別，目前 aec3 和 speex 中都採用這種結構，可見 WebRTC AEC 中線性部分還有很大的優化空間。
圖 6 近端信號與估計的回聲信號的對比
如何衡量改進的線性部分效果？
這裏咱們對比了現有的固定步長的 NLMS 和變步長的 NLMS，近端信號 d(n) 爲加混響的遠端參考信號 x(n) + 近端語音信號 s(n)。理論上 NLMS 在處理這種純線性疊加的信號時，能夠不用非線性部分出馬，直接幹掉遠端回聲信號。圖 7(a) 第一行爲近端信號 d(n)，第二列爲遠端參考信號 x(n)，線性部分輸出結果，黃色框中爲遠端信號。WebRTC AEC 中採用固定步長的 NLMS 算法收斂較慢，有些許回聲殘留。可是變步長的 NLMS 收斂較快，回聲抑制相對好一些，如圖 7(b)。
圖 7 兩種 NLMS 算法的效果對比
線性濾波器參數設置
#define FRAME_LEN 80
#define PART_LEN 64
enum { kExtendedNumPartitions = 32 };
static const int kNormalNumPartitions = 12;
FRAME_LEN 爲每次傳給音頻 3A 模塊的數據的長度，默認爲 80 個採樣點，因爲 WebRTC AEC 採用了 128 點 FFT，內部拼幀邏輯會取出 PART_LEN = 64 個樣本點與前一幀剩餘數據鏈接成128點作 FFT，剩餘的 16 點遺留到下一次，所以實際每次處理 PART_LEN 個樣本點（4ms 數據）。
默認濾波器階數僅爲 kNormalNumPartitions = 12 個，可以覆蓋的數據範圍爲 kNormalNumPartitions * 4ms = 48ms，若是打開擴展濾波器模式(設置 extended_filter_enabled爲true)，覆蓋數據範圍爲 kNormalNumPartitions * 4ms = 132ms。隨着芯片處理能力的提高，默認會打開這個擴展濾波器模式，甚至擴展爲更高的階數，以此來應對市面上絕大多數的移動設備。另外，線性濾波器雖然不具有調整延時的能力，但能夠經過估計的 index 衡量當前信號的延時狀態，範圍爲 [0, kNormalNumPartitions]，若是 index 處於做用域兩端，說明真實延時太小或過大，會影響線性回聲估計的效果，嚴重的會帶來回聲，此時須要結合固定延時與大延時檢測來修正。
非線性濾波
非線性部分一共作了兩件事，就是想盡想方設法幹掉遠端信號。
(1) 根據線性部分提供的估計的回聲信號，計算信號間的相干性，判別遠近端幀狀態。
(2) 調整抑制係數，計算非線性濾波參數。
非線性濾波抑制係數爲 hNl，大體表徵着估計的回聲信號 e(n) 中，指望的近端成分與殘留的非線性回聲信號 y''(n) 在不一樣頻帶上的能量比，hNl 是與相干值是一致的，範圍是 [0，1.0]，經過圖 5(b) 能夠看出須要消除的遠端部分幅度值也廣泛在 0.5 左右，若是直接使用 hNl 濾波會致使大量的回聲殘留。
所以 WebRTC 工程師對 hNl 作了以下尺度變換，over_drive 與 nlp_mode 相關，表明不一樣的抑制激進程度，drive_curve 是一條單調遞增的凸曲線，範圍 [1.0, 2.0]。因爲中高頻的尾音在聽感上比較明顯，因此他們設計了這樣的抑制曲線來抑制高頻尾音。咱們記尺度變換的 α = over_drive_scaling * drive_curve，若是設置 nlp_mode = kAecNlpAggressive，α 大約會在 30 左右。
% matlab代碼以下： over_drive = min_override(nlp_mode+1); if (over_drive < over_drive_scaling) over_drive_scaling = 0.99*over_drive_scaling + 0.01*over_drive; % default 0.99 0.01 else over_drive_scaling = 0.9*over_drive_scaling + 0.1*over_drive; % default 0.9 0.1 end % WebRtcAec_Overdrive →_→ Overdrive hNl(index) = weight_curve(index).*hNlFb + (1-weight_curve(index)).* hNl(index); hNl = hNl.^(over_drive_scaling * drive_curve); % WebRtcAec_Suppress →_→ Suppress wined_fft_echo = wined_fft_echo .*hNl; wined_fft_echo = conj(wined_fft_echo);
若是當前幀爲近端幀（即 echo_state = false），假設第 k 個頻帶 hNl(k) = 0.99994 ，hNl(k) = hNl(k)^α = 0.99994 ^ 30 = 0.9982，即便濾波後的損失聽感上幾乎無感知。如圖 8(a)，hNl 通過 α 調製以後，幅值依然很接近 1.0。
若是當前幀爲遠端幀（即 echo_state = true），假設第 k 個頻帶 hNl(k) = 0.6676 ，hNl(k) = hNl(k)^α = 0.6676 ^ 30 = 5.4386e-06，濾波後遠端能量小到基本聽不到了。如圖 8(b)，hNl 通過 α 調製以後，基本接近 0。
圖 8 遠近端信號抑制係數在調製先後的變化
通過如上對比，爲了保證通過調製以後近端指望信號失真最小，遠端回聲能夠被抑制到不可聽，WebRTC AEC 纔在遠近端幀狀態判斷的的模塊中設置瞭如此嚴格的門限。
另外，調整係數 α 過於嚴格的狀況下會帶來雙講的抑制，如圖 9 第 1 行，近端說話人聲音明顯丟失，經過調整 α 後得以恢復，如第 2 行所示。所以若是在 WebRTC AEC 現有策略上優化 α 估計，能夠緩解雙講抑制嚴重的問題。
延時調整策略
回聲消除的效果與遠近端數據延時強相關，調整不當會帶來算法不可用的風險。在遠近端數據進入線性部分以前，必定要保證延時在設計的濾波器階數範圍內，否則延時過大超出了線性濾波器估計的範圍或調整過當致使遠近端非因果都會形成沒法收斂的回聲。先科普兩個問題：
（1）爲何會存在延時？
首先近端信號 d(n) 中的回聲是揚聲器播放遠端參考 x(n)，又被麥克風採集到的造成的，也就意味着在近端數據還未採集進來以前，遠端數據緩衝區中已經躺着 N 幀 x(n)了，這個自然的延時能夠約等於音頻信號從準備渲染到被麥克風採集到的時間，不一樣設備這個延時是不等的。蘋果設備延時較小，基本在 120ms 左右，Android 設備廣泛在 200ms 左右，低端機型上會有 300ms 左右甚至以上。
（2）遠近端非因果爲何會致使回聲？
從（1）中能夠認爲，正常狀況下當前幀近端信號爲了找到與之對齊的遠端信號，必須在遠端緩衝區沿着寫指針向前查找。若是此時設備採集丟數據，遠端數據會迅速消耗，致使新來的近端幀在向前查找時，已經找不到與之對齊的遠端參考幀了，會致使後續各模塊工做異常。如圖 10(a) 表示正常延時狀況，(b) 表示非因果。
圖10 正常遠近端延時與非因果
WebRTC AEC 中的延時調整策略關鍵並且複雜，涉及到固定延時調整，大延時檢測，以及線性濾波器延時估計。三者的關係以下：
① 固定延時調整隻會發生在開始 AEC 算法開始處理以前，並且僅調整一次。如會議盒子等固定的硬件設備延時基本是固定的，能夠經過直接減去固定的延時的方法縮小延時估計範圍，使之快速來到濾波器覆蓋的延時範圍以內。 下面結合代碼來看看固定延時的調整過程：
int32_t WebRtcAec_Process(void* aecInst, const float* const* nearend, size_t num_bands, float* const* out, size_t nrOfSamples, int16_t reported_delay_ms, int32_t skew);
WebRtcAec_Process 接口如上，參數 reported_delay_ms 爲當前設備須要調整延時的目標值。如某 Android 設備固定延時爲 400ms 左右，400ms 已經超出濾波器覆蓋的延時範圍，至少須要調整 300ms 延時，才能知足回聲消除沒有回聲的要求。固定延時調整在 WebRTC AEC 算法開始之初僅做用一次：
if (self->startup_phase) {
int startup_size_ms = reported_delay_ms < kFixedDelayMs ? kFixedDelayMs : reported_delay_ms;
int target_delay = startup_size_ms * self->rate_factor * 8;
int overhead_elements = (WebRtcAec_system_delay_aliyun(self->aec) - target_delay) / PART_LEN;
printf("[audio] target_delay = %d, startup_size_ms = %d, self->rate_factor = %d, sysdelay = %d, overhead_elements = %d\n", target_delay, startup_size_ms, self->rate_factor, WebRtcAec_system_delay(self->aec), overhead_elements);
WebRtcAec_AdjustFarendBufferSizeAndSystemDelay_aliyun(self->aec, overhead_elements);
self->startup_phase = 0;
}
爲何 target_delay 是這麼計算？
int target_delay = startup_size_ms * self->rate_factor * 8; startup_size_ms 其實就是設置下去的 reported_delay_ms，這一步將計算時間毫秒轉化爲樣本點數。16000hz 採樣中，10ms 表示 160 個樣本點，所以 target_delay 實際就是須要調整的目標樣本點數（aecpc->rate_factor = aecpc->splitSampFreq / 8000 = 2）。
咱們用 330ms 延時的數據測試： 若是設置默認延時爲 240ms，overhead_elements 第一次被調整了 -60 個 block，負值表示向前查找，正好爲 60 * 4 = 240ms，以後線性濾波器固定 index = 24，表示 24 * 4 = 96ms 延時，兩者之和約等於 330ms。日誌打印以下：
② 大延時檢測是基於遠近端數據類似性在遠端大緩存中查找最類似的幀的過程，其算法原理有點相似音頻指紋中特徵匹配的思想。大延時調整的能力是對固定延時調整與線型濾波器能力的補充，使用它的時候須要比較慎重，須要控制調整的頻率，以及控制形成非因果的風險。
WebRTC AEC 算法中開闢了可存儲 250 個 block 大緩衝區，每一個 block 的長度 PART_LEN = 64 個樣本點，可以保存最新的 1s 的數據，這也是理論上的大延時可以估計的範圍，絕對夠用了。
static const size_t kBufferSizeBlocks = 250; buffer_ = WebRtc_CreateBuffer(kBufferSizeBlocks, sizeof(float) * PART_LEN); aec->delay_agnostic_enabled = 1;
咱們用 610ms 延時的數據測試(啓用大延時調整須要設置 delay_agnostic_enabled = 1)： 咱們仍是設置默認延時爲 240ms，剛開始仍是調整了 -60 個 block，隨後大延時調整接入以後有調整了 -88 個 block，一共調整(60 + 88) * 4 = 592ms，以後線性濾波器固定 index = 4，表示最後剩餘延時剩餘 16ms，符合預期。
③ 線性濾波器延時估計是固定延時調整和大延時調整以後，濾波器對當前遠近端延時的最直接反饋。前二者調整不當會形成延時太小甚至非因果，或延時過大超出濾波器覆蓋能力，致使沒法收斂的回聲。所以前二者在調整的過程當中須要結合濾波器的能力，確保剩餘延時在濾波器可以覆蓋的範圍以內，即便延時小範圍抖動，線性部分也能自適應調整。
總結與優化方向
WebRTC AEC 存在的問題：
（1）線性部分收斂時間較慢，固定步長的 NLMS 算法對線性部分回聲的估計欠佳； （2）線性部分濾波器階數默認爲 32 階，默認覆蓋延時 132ms，對移動端延時較大設備支持不是很好，大延時檢測部分介入較慢，且存在誤調致使非因果回聲的風險； （3）基於相干性的幀狀態依賴嚴格的固定門限，存在必定程度的誤判，若是再去指導非線性部分抑制係數的調節，會帶來比較嚴重的雙講抑制。
優化的方向： （1）算法上能夠經過學習 speex 和 AEC3 的線性部分，改善當前線性濾波效果； （2）算法上能夠優化延時調整策略，工程上能夠新增參數配置下發等工程手段解決一些設備的延時問題； （3）另外，有一些新的思路也是值得咱們嘗試的，如開頭提到的，既然回聲也能夠是視爲噪聲，那麼可否用降噪的思路作回聲消除呢，答案是能夠的。
「視頻雲技術」你最值得關注的音視頻技術公衆號，每週推送來自阿里雲一線的實踐技術文章，在這裏與音視頻領域一流工程師交流切磋。