回聲消除(回聲消除是什么意思)

作者:珞神

來源:微信公眾號(hào):視頻云技術(shù)

出處:https://mp.weixin.qq.com/s/iq6EWCQHoYTtAwZBzs8tYA

前言：近年來，音視頻會(huì)議產(chǎn)品提升著工作協(xié)同的效率，在線教育產(chǎn)品突破著傳統(tǒng)教育形式的種種限制，娛樂互動(dòng)直播產(chǎn)品豐富著生活社交的多樣性，背后都離不開音視頻通信技術(shù)的優(yōu)化與創(chuàng)新，其中音頻信息內(nèi)容傳遞的流暢性、完整性、可懂度直接決定著用戶之間的溝通質(zhì)量。自 2011 年 WebRTC 開源以來，無論是其技術(shù)架構(gòu)，還是其中豐富的算法模塊都是值得我們細(xì)細(xì)品味，音頻方面熟知的 3A 算法（AGC: Automatic gain control; ANS: Adaptive noi suppression; AEC: Acoustic echo cancellation）就是其中閃閃發(fā)光的明珠。本文章將結(jié)合實(shí)例全面解析 WebRTC AEC 的基本框架和基本原理，一起探索回聲消除的基本原理，技術(shù)難點(diǎn)以及優(yōu)化方向。

作者 ： 珞神，阿里云高級(jí)開發(fā)工程師

負(fù)責(zé)阿里云 RTC 音頻研發(fā)

回聲的形成

WebRTC 架構(gòu)中上下行音頻信號(hào)處理流程如圖 1，音頻 3A 主要集中在上行的發(fā)送端對(duì)發(fā)送信號(hào)依次進(jìn)行回聲消除、降噪以及音量均衡（這里只討論 AEC 的處理流程，如果是 AECM 的處理流程 ANS 會(huì)前置），AGC 會(huì)作為壓限器作用在接收端對(duì)即將播放的音頻信號(hào)進(jìn)行限幅。

圖 1 WebRTC 中音頻信號(hào)上下行處理流程框圖

那么回聲是怎么形成的呢？

如圖 2 所示，A、B 兩人在通信的過程中，我們有如下定義：

x(n): 遠(yuǎn)端參考信號(hào)，即 A 端訂閱的 B 端音頻流，通常作為參考信號(hào)；

y(n) : 回聲信號(hào)，即揚(yáng)聲器播放信號(hào) x(n) 后，被麥克風(fēng)采集到的信號(hào)，此時(shí)經(jīng)過房間混響以及麥克風(fēng)采集的信號(hào) y(n) 已經(jīng)不能等同于信號(hào) x(n) 了, 我們記線性疊加的部分為 y'(n), 非線性疊加的部分為 y''(n), y(n) = y'(n) + y''(n)；

s(n) : 麥克風(fēng)采集的近端說話人的語(yǔ)音信號(hào)，即我們真正想提取并發(fā)送到遠(yuǎn)端的信號(hào)；

v(n) ：環(huán)境噪音，這部分信號(hào)會(huì)在 ANS 中被削弱；

d(n) : 近端信號(hào)，即麥克風(fēng)采集之后，3A 之前的原始信號(hào)，可以表示為：d(n) = s(n) + y(n) + v(n)；

s'(n): 3A 之后的音頻信號(hào)，即準(zhǔn)備經(jīng)過編碼發(fā)送到對(duì)端的信號(hào)。

WebRTC 音頻引擎能夠拿到的已知信號(hào)只有近端信號(hào) d(n) 和遠(yuǎn)端參考信號(hào) x(n) 。

圖 2 回聲信號(hào)生成模型

如果信號(hào)經(jīng)過 A 端音頻引擎得到 s'(n) 信號(hào)中依然殘留信號(hào) y(n)，那么 B 端就能聽到自己回聲或殘留的尾音（回聲抑制不徹底留下的殘留）。AEC 效果評(píng)估在實(shí)際情況中可以粗略分為如下幾種情況（專業(yè)人員可根據(jù)應(yīng)用場(chǎng)景、設(shè)備以及單雙講進(jìn)一步細(xì)分）：

回聲消除的本質(zhì)

在解析 WebRTC AEC 架構(gòu)之前，我們需要了解回聲消除的本質(zhì)是什么。音視頻通話過程中，聲音是傳達(dá)信息的主要途徑，因此從復(fù)雜的錄音信號(hào)中，通過信號(hào)處理的手段使得我們要傳遞的信息：高保真、低延時(shí)、清晰可懂是一直以來追求的目標(biāo)。在我看來，回聲消除，噪聲抑制和聲源分離同屬于語(yǔ)音增強(qiáng)的范疇，如果把噪聲理解為廣義的噪聲三者之間的關(guān)系如下圖：

圖 3 語(yǔ)音增強(qiáng)與回聲消除的關(guān)系

噪聲抑制 需要準(zhǔn)確估計(jì)出噪聲信號(hào)，其中平穩(wěn)噪聲可以通過語(yǔ)音檢測(cè)判別有話端與無話端的狀態(tài)來動(dòng)態(tài)更新噪聲信號(hào)，進(jìn)而參與降噪，常用的手段是基于譜減法(即在原始信號(hào)的基礎(chǔ)上減去估計(jì)出來的噪聲所占的成分)的一系列改進(jìn)方法，其效果依賴于對(duì)噪聲信號(hào)估計(jì)的準(zhǔn)確性。對(duì)于非平穩(wěn)噪聲，目前用的較多的就是基于遞歸神經(jīng)網(wǎng)絡(luò)的深度學(xué)習(xí)方法，很多 Windows 設(shè)備上都內(nèi)置了基于多麥克風(fēng)陣列的降噪的算法。效果上，為了保證音質(zhì)，噪聲抑制允許噪聲殘留，只要比原始信號(hào)信噪比高，噪且聽覺上失真無感知即可。

單聲道的聲源分離 技術(shù)起源于傳說中的雞尾酒會(huì)效應(yīng)，是指人的一種聽力選擇能力，在這種情況下，注意力集中在某一個(gè)人的談話之中而忽略背景中其他的對(duì)話或噪音。該效應(yīng)揭示了人類聽覺系統(tǒng)中令人驚奇的能力，即我們可以在噪聲中談話。科學(xué)家們一直在致力于用技術(shù)手段從單聲道錄音中分離出各種成分，一直以來的難點(diǎn)，隨著機(jī)器學(xué)習(xí)技術(shù)的應(yīng)用，使得該技術(shù)慢慢變成了可能，但是較高的計(jì)算復(fù)雜度等原因，距離 RTC 這種低延時(shí)系統(tǒng)中的商用還是有一些距離。

噪聲抑制與聲源分離都是單源輸入，只需要近端采集信號(hào)即可，傲嬌的回聲消除需要同時(shí)輸入近端信號(hào)與遠(yuǎn)端參考信號(hào)。有同學(xué)會(huì)問已知了遠(yuǎn)端參考信號(hào)，為什么不能用噪聲抑制方法處理呢，直接從頻域減掉遠(yuǎn)端信號(hào)的頻譜不就可以了嗎？

上圖中第一行為近端信號(hào) s(n)，已經(jīng)混合了近端人聲和揚(yáng)聲器播放出來的遠(yuǎn)端信號(hào)，黃色框中已經(jīng)標(biāo)出對(duì)齊之后的遠(yuǎn)端信號(hào)，其語(yǔ)音表達(dá)的內(nèi)容一致，但是頻譜和幅度(明顯經(jīng)過揚(yáng)聲器放大之后聲音能量很高)均不一致，意思就是：參考的遠(yuǎn)端信號(hào)與揚(yáng)聲器播放出來的遠(yuǎn)端信號(hào)已經(jīng)是“貌合神離”了，與降噪的方法相結(jié)合也是不錯(cuò)的思路，但是直接套用降噪的方法顯然會(huì)造成回聲殘留與雙講部分嚴(yán)重的抑制。接下來，我們來看看 WebRTC 科學(xué)家是怎么做的吧。

信號(hào)處理流程

WebRTC AEC 算法包含了延時(shí)調(diào)整策略，線性回聲估計(jì)，非線性回聲抑制 3 個(gè)部分。回聲消除本質(zhì)上更像是音源分離，我們期望從混合的近端信號(hào)中消除不需要的遠(yuǎn)端信號(hào)，保留近端人聲發(fā)送到遠(yuǎn)端，但是 WebRTC 工程師們更傾向于將兩個(gè)人交流的過程理解為一問一答的交替說話，存在遠(yuǎn)近端同時(shí)連續(xù)說話的情況并不多（即保單講輕雙講）。

因此只需要區(qū)分遠(yuǎn)近端說話區(qū)域就可以通過一些手段消除絕大多數(shù)遠(yuǎn)端回聲，至于雙講恢復(fù)能力 WebRTC AEC 算法提供了 {kAecNlpConrvative, kAecNlpModerate, kAecNlpAggressive} 3 個(gè)模式，由低到高依次代表不同的抑制程度，遠(yuǎn)近端信號(hào)處理流程如圖 4：

圖 4 WebRTC AEC 算法結(jié)構(gòu)框圖

NLMS 自適應(yīng)算法（上圖中橙色部分）的運(yùn)用旨在盡可能地消除信號(hào) d(n) 中的線性部分回聲，而殘留的非線性回聲信號(hào)會(huì)在非線性濾波（上圖中紫色部分）部分中被消除，這兩個(gè)模塊是 Webrtc AEC 的核心模塊。模塊前后依賴，現(xiàn)實(shí)場(chǎng)景中遠(yuǎn)端信號(hào) x(n) 由揚(yáng)聲器播放出來在被麥克風(fēng)采集的過程中，同時(shí)包含了回聲 y(n) 與近端信號(hào) x(n) 的線性疊加和非線性疊加：需要消除線性回聲的目的是為了增大近端信號(hào) X(ω) 與濾波結(jié)果 E(ω) 之間的差異，計(jì)算相干性時(shí)差異就越大（近端信號(hào)接近 1，而遠(yuǎn)端信號(hào)部分越接近 0），更容易通過門限直接區(qū)分近端幀與遠(yuǎn)端幀。非線性濾波部分中只需要根據(jù)檢測(cè)的幀類型，調(diào)節(jié)抑制系數(shù)，濾波消除回聲即可。下面我們結(jié)合實(shí)例分析這套架構(gòu)中的線性部分與非線性分。

線性濾波

線性回聲 y'(n) 可以理解為是遠(yuǎn)端參考信號(hào) x(n) 經(jīng)過房間沖擊響應(yīng)之后的結(jié)果，線性濾波的本質(zhì)也就是在估計(jì)一組濾波器使得 y'(n) 盡可能的等于 x(n)，通過統(tǒng)計(jì)濾波器組的最大幅值位置 index 找到與之對(duì)齊遠(yuǎn)端信號(hào)幀，該幀數(shù)據(jù)會(huì)參與相干性計(jì)算等后續(xù)模塊。

需要注意的是，如果 index 在濾波器階數(shù)兩端瘋狂試探，只能說明當(dāng)前給到線性部分的遠(yuǎn)近端延時(shí)較小或過大，此時(shí)濾波器效果是不穩(wěn)定的，需要借助固定延時(shí)調(diào)整或大延時(shí)調(diào)整使 index 處于一個(gè)比較理想的位置。線性部分算法是可以看作是一個(gè)固定步長(zhǎng)的 NLMS 算法，具體細(xì)節(jié)大家可以結(jié)合源碼走讀，本節(jié)重點(diǎn)講解線型濾波在整個(gè)框架中的作用。

從個(gè)人理解來看，線性部分的目的就是最大程度的消除線性回聲，為遠(yuǎn)近端幀判別的時(shí)候，最大程度地保證了信號(hào)之間的相干值( 0~1 之間，值越大相干性越大)的可靠性。

我們記消除線性回聲之后的信號(hào)為估計(jì)的回聲信號(hào) e(n)，e(n) = s(n) + y''(n) + v(n)，其中 y''(n) 為非線性回聲信號(hào)，記 y'(n) 為線性回聲，y(n) = y'(n) + y''(n)。相干性的計(jì)算 （Matlab代碼）：

% WebRtcAec_UpdateCoherenceSpectra →_→ UpdateCoherenceSpectraSd = 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 →_→ ComputeCoherencecohde = (abs(Sde).*abs(Sde))./(Sd.*Se + 1.0e-10);cohdx = (abs(Sxd).*abs(Sxd))./(Sx.*Sd + 1.0e-10);兩個(gè)實(shí)驗(yàn)

（1）計(jì)算近端信號(hào) d(n) 與遠(yuǎn)端參考信號(hào) x(n) 的相關(guān)性 cohdx，理論上遠(yuǎn)端回聲信號(hào)的相干性應(yīng)該更接近 0（為了方便后續(xù)對(duì)比，WebRTC 做了反向處理: 1 - cohdx），如圖 5(a)，第一行為計(jì)算近端信號(hào) d(n)，第二行為遠(yuǎn)端參考信號(hào) x(n)，第三行為二者相干性曲線: 1 - cohdx，會(huì)發(fā)現(xiàn)回聲部分相干值有明顯起伏，最大值有0.7，近端部分整體接近 1.0，但是有持續(xù)波動(dòng)，如果想通過一條固定的門限去區(qū)分遠(yuǎn)近端幀，會(huì)存在不同程度的誤判，反映到聽感上就是回聲（遠(yuǎn)端判斷成近端）或丟字（近端判斷為遠(yuǎn)端）。

(a) 近端信號(hào)與遠(yuǎn)端參考信號(hào)的相干性

(b) 近端信號(hào)與估計(jì)的回聲信號(hào)的相干性

圖 5 信號(hào)的相干性

（2）計(jì)算近端信號(hào) d(n) 與估計(jì)的回聲信號(hào) e(n) 的相干性，如圖 5(b)，第二行為估計(jì)的回聲信號(hào) e(n)，第三行為二者相干性 cohde，很明顯近端的部分幾乎全部逼近 1.0，WebRTC 用比較嚴(yán)格的門限（>=0.98）即可將區(qū)分絕大部分近端幀，且誤判的概率比較小，WebRTC 工程師設(shè)置如此嚴(yán)格的門限想必是寧可犧牲一部分雙講效果，也不愿意接受回聲殘留。

從圖 5 可以體會(huì)到，線性濾波之后可以進(jìn)一步凸顯遠(yuǎn)端參考信號(hào) x(n) 與估計(jì)的回聲信號(hào) e(n) 的差異，從而提高遠(yuǎn)近端幀狀態(tài)的判決的可靠性。

理想情況下，遠(yuǎn)端信號(hào)從揚(yáng)聲器播放出來沒有非線性失真，那么 e(n) = s(n) + v(n)，但實(shí)際情況下 e(n)與d(n) 很像，只是遠(yuǎn)端區(qū)域有一些幅度上的變化，說明 WebRTC AEC 線性部分在這個(gè) ca 中表現(xiàn)不佳，如圖 6(a) 從頻譜看低頻段明顯削弱，但中高頻部分幾乎沒變。而利用變步長(zhǎng)的雙濾波器結(jié)構(gòu)的結(jié)果會(huì)非常明顯，如圖 6(b) 所示無論是時(shí)域波形和頻譜與近端信號(hào) x(n) 都有很大差異，目前 aec3 和 speex 中都采用這種結(jié)構(gòu)，可見 WebRTC AEC 中線性部分還有很大的優(yōu)化空間。

(a) WebRTC AEC 線性部分輸出

( b) 改進(jìn)的線性部分輸出

圖 6 近端信號(hào)與估計(jì)的回聲信號(hào)的對(duì)比

如何衡量改進(jìn)的線性部分效果？

這里我們對(duì)比了現(xiàn)有的固定步長(zhǎng)的 NLMS 和變步長(zhǎng)的 NLMS，近端信號(hào) d(n) 為加混響的遠(yuǎn)端參考信號(hào) x(n) + 近端語(yǔ)音信號(hào) s(n)。理論上 NLMS 在處理這種純線性疊加的信號(hào)時(shí)，可以不用非線性部分出馬，直接干掉遠(yuǎn)端回聲信號(hào)。圖 7(a) 第一行為近端信號(hào) d(n)，第二列為遠(yuǎn)端參考信號(hào) x(n)，線性部分輸出結(jié)果，黃色框中為遠(yuǎn)端信號(hào)。WebRTC AEC 中采用固定步長(zhǎng)的 NLMS 算法收斂較慢，有些許回聲殘留。但是變步長(zhǎng)的 NLMS 收斂較快，回聲抑制相對(duì)好一些，如圖 7(b)。

（a）固定步長(zhǎng)的 NLMS

（b） 變步長(zhǎng)的 NLMS

圖 7 兩種 NLMS 算法的效果對(duì)比

#define FRAME_LEN 80#define PART_LEN 64enum { kExtendedNumPartitions = 32 };static const int kNormalNumPartitions = 12;

FRAME_LEN 為每次傳給音頻 3A 模塊的數(shù)據(jù)的長(zhǎng)度，默認(rèn)為 80 個(gè)采樣點(diǎn)，由于 WebRTC AEC 采用了 128 點(diǎn) FFT，內(nèi)部拼幀邏輯會(huì)取出 PART_LEN = 64 個(gè)樣本點(diǎn)與前一幀剩余數(shù)據(jù)連接成128點(diǎn)做 FFT，剩余的 16 點(diǎn)遺留到下一次，因此實(shí)際每次處理 PART_LEN 個(gè)樣本點(diǎn)（4ms 數(shù)據(jù)）。

默認(rèn)濾波器階數(shù)僅為 kNormalNumPartitions = 12 個(gè)，能夠覆蓋的數(shù)據(jù)范圍為 kNormalNumPartitions * 4ms = 48ms， 如果打開擴(kuò)展濾波器模式(設(shè)置 extended_filter_enabled為true)，覆蓋數(shù)據(jù)范圍為 kNormalNumPartitions * 4ms = 132 ms 。隨著芯片處理能力的提升，默認(rèn)會(huì)打開這個(gè)擴(kuò)展濾波器模式，甚至擴(kuò)展為更高的階數(shù)，以此來應(yīng)對(duì)市面上絕大多數(shù)的移動(dòng)設(shè)備。另外，線性濾波器雖然不具備調(diào)整延時(shí)的能力，但可以通過估計(jì)的 index 衡量當(dāng)前信號(hào)的延時(shí)狀態(tài)，范圍為 [ 0 , kNormalNumPartitions ]，如果 index 處于作用域兩端，說明真實(shí)延時(shí)過小或過大，會(huì)影響線性回聲估計(jì)的效果，嚴(yán)重的會(huì)帶來回聲，此時(shí)需要結(jié)合固定延時(shí)與大延時(shí)檢測(cè)來修正。

非線性部分一共做了兩件事，就是想盡千方百計(jì)干掉遠(yuǎn)端信號(hào)。

(1) 根據(jù)線性部分提供的估計(jì)的回聲信號(hào)，計(jì)算信號(hào)間的相干性，判別遠(yuǎn)近端幀狀態(tài)。

(2) 調(diào)整抑制系數(shù)，計(jì)算非線性濾波參數(shù)。

非線性濾波抑制系數(shù)為 hNl，大致表征著估計(jì)的回聲信號(hào) e(n) 中，期望的近端成分與殘留的非線性回聲信號(hào) y''(n) 在不同頻帶上的能量比，hNl 是與相干值是一致的，范圍是 [0，1.0]，通過圖 5(b) 可以看出需要消除的遠(yuǎn)端部分幅度值也普遍在 0.5 左右，如果直接使用 hNl 濾波會(huì)導(dǎo)致大量的回聲殘留。

因此 WebRTC 工程師對(duì) hNl 做了如下尺度變換，over_drive 與 nlp_mode 相關(guān)，代表不同的抑制激進(jìn)程度，drive_curve 是一條單調(diào)遞增的凸曲線，范圍 [1.0, 2.0]。由于中高頻的尾音在聽感上比較明顯，所以他們?cè)O(shè)計(jì)了這樣的抑制曲線來抑制高頻尾音。我們記尺度變換的 α = over_drive_scaling * drive_curve，如果設(shè)置 nlp_mode = kAecNlpAggressive，α 大約會(huì)在 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.01el over_drive_scaling = 0.9*over_drive_scaling + 0.1*over_drive; % default 0.9 0.1end % WebRtcAec_Overdrive →_→ OverdrivehNl(index) = weight_curve(index).*hNlFb + (1-weight_curve(index)).* hNl(index);hNl = hNl.^(over_drive_scaling * drive_curve); % WebRtcAec_Suppress →_→ Suppresswined_fft_echo = wined_fft_echo .*hNl;wined_fft_echo = conj(wined_fft_echo);

如果當(dāng)前幀為近端幀（即 echo_state = fal），假設(shè)第 k 個(gè)頻帶 hNl(k) = 0.99994 ，hNl(k) = hNl(k)^α = 0.99994 ^ 30 = 0.9982，即使濾波后的損失聽感上幾乎無感知。如圖 8(a)，hNl 經(jīng)過 α 調(diào)制之后，幅值依然很接近 1.0。

如果當(dāng)前幀為遠(yuǎn)端幀（即 echo_state = true），假設(shè)第 k 個(gè)頻帶 hNl(k) = 0.6676 ，hNl(k) = hNl(k)^α = 0.6676 ^ 30 = 5.4386e-06，濾波后遠(yuǎn)端能量小到基本聽不到了。如圖 8(b)，hNl 經(jīng)過 α 調(diào)制之后，基本接近 0。

（a）近端幀對(duì)應(yīng)的抑制系數(shù)

（b）遠(yuǎn)端幀對(duì)應(yīng)的抑制系數(shù)

圖 8 遠(yuǎn)近端信號(hào)抑制系數(shù)在調(diào)制前后的變化

經(jīng)過如上對(duì)比，為了保證經(jīng)過調(diào)制之后近端期望信號(hào)失真最小，遠(yuǎn)端回聲可以被抑制到不可聽，WebRTC AEC 才在遠(yuǎn)近端幀狀態(tài)判斷的的模塊中設(shè)置了如此嚴(yán)格的門限。

另外，調(diào)整系數(shù) α 過于嚴(yán)格的情況下會(huì)帶來雙講的抑制，如圖 9 第 1 行，近端說話人聲音明顯丟失，通過調(diào)整 α 后得以恢復(fù)，如第 2 行所示。因此如果在 WebRTC AEC 現(xiàn)有策略上優(yōu)化 α 估計(jì)，可以緩解雙講抑制嚴(yán)重的問題。

圖 9 雙講效果

延時(shí)調(diào)整策略

回聲消除的效果與遠(yuǎn)近端數(shù)據(jù)延時(shí)強(qiáng)相關(guān)，調(diào)整不當(dāng)會(huì)帶來算法不可用的風(fēng)險(xiǎn)。在遠(yuǎn)近端數(shù)據(jù)進(jìn)入線性部分之前，一定要保證延時(shí)在設(shè)計(jì)的濾波器階數(shù)范圍內(nèi)，不然延時(shí)過大超出了線性濾波器估計(jì)的范圍或調(diào)整過當(dāng)導(dǎo)致遠(yuǎn)近端非因果都會(huì)造成無法收斂的回聲。先科普兩個(gè)問題：

（1）為什么會(huì)存在延時(shí)？

首先近端信號(hào) d(n) 中的回聲是揚(yáng)聲器播放遠(yuǎn)端參考 x(n)，又被麥克風(fēng)采集到的形成的，也就意味著在近端數(shù)據(jù)還未采集進(jìn)來之前，遠(yuǎn)端數(shù)據(jù)緩沖區(qū)中已經(jīng)躺著 N 幀 x(n)了，這個(gè)天然的延時(shí)可以約等于音頻信號(hào)從準(zhǔn)備渲染到被麥克風(fēng)采集到的時(shí)間，不同設(shè)備這個(gè)延時(shí)是不等的。蘋果設(shè)備延時(shí)較小，基本在 120ms 左右，Android 設(shè)備普遍在 200ms 左右，低端機(jī)型上會(huì)有 300ms 左右甚至以上。

（2）遠(yuǎn)近端非因果為什么會(huì)導(dǎo)致回聲？

從（1）中可以認(rèn)為，正常情況下當(dāng)前幀近端信號(hào)為了找到與之對(duì)齊的遠(yuǎn)端信號(hào)，必須在遠(yuǎn)端緩沖區(qū)沿著寫指針向前查找。如果此時(shí)設(shè)備采集丟數(shù)據(jù)，遠(yuǎn)端數(shù)據(jù)會(huì)迅速消耗，導(dǎo)致新來的近端幀在向前查找時(shí)，已經(jīng)找不到與之對(duì)齊的遠(yuǎn)端參考幀了，會(huì)導(dǎo)致后續(xù)各模塊工作異常。如圖 10(a) 表示正常延時(shí)情況，(b) 表示非因果。

（a）遠(yuǎn)近端正常延時(shí)

（b）遠(yuǎn)近端非因果

圖10 正常遠(yuǎn)近端延時(shí)與非因果

WebRTC AEC 中的延時(shí)調(diào)整策略關(guān)鍵而且復(fù)雜，涉及到固定延時(shí)調(diào)整，大延時(shí)檢測(cè)，以及線性濾波器延時(shí)估計(jì)。三者的關(guān)系如下：

① 固定延時(shí)調(diào)整 只會(huì)發(fā)生在開始 AEC 算法開始處理之前，而且僅調(diào)整一次。如會(huì)議盒子等固定的硬件設(shè)備延時(shí)基本是固定的，可以通過直接減去固定的延時(shí)的方法縮小延時(shí)估計(jì)范圍，使之快速來到濾波器覆蓋的延時(shí)范圍之內(nèi)。

下面結(jié)合代碼來看看固定延時(shí)的調(diào)整過程：

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 接口如上，參數(shù) reported_delay_ms 為當(dāng)前設(shè)備需要調(diào)整延時(shí)的目標(biāo)值。如某 Android 設(shè)備固定延時(shí)為 400ms 左右，400ms 已經(jīng)超出濾波器覆蓋的延時(shí)范圍，至少需要調(diào)整 300ms 延時(shí)，才能滿足回聲消除沒有回聲的要求。固定延時(shí)調(diào)整在 WebRTC AEC 算法開始之初僅作用一次：

if (lf->startup_pha) { int startup_size_ms = reported_delay_ms < kFixedDelayMs ? kFixedDelayMs : reported_delay_ms; int target_delay = startup_size_ms * lf->rate_factor * 8; int overhead_elements = (WebRtcAec_system_delay_aliyun(lf->aec) - target_delay) / PART_LEN; printf("[audio] target_delay = %d, startup_size_ms = %d, lf->rate_factor = %d, sysdelay = %d, overhead_elements = %d ", target_delay, startup_size_ms, lf->rate_factor, WebRtcAec_system_delay(lf->aec), overhead_elements); WebRtcAec_AdjustFarendBufferSizeAndSystemDelay_aliyun(lf->aec, overhead_elements);lf->startup_pha = 0; }

為什么 target_delay 是這么計(jì)算？

int target_delay = startup_size_ms * lf->rate_factor * 8;

startup_size_ms 其實(shí)就是設(shè)置下去的 reported_delay_ms，這一步將計(jì)算時(shí)間毫秒轉(zhuǎn)化為樣本點(diǎn)數(shù)。16000hz 采樣中，10ms 表示 160 個(gè)樣本點(diǎn)，因此 target_delay 實(shí)際就是需要調(diào)整的目標(biāo)樣本點(diǎn)數(shù)（aecpc->rate_factor = aecpc->splitSampFreq / 8000 = 2）。

我們用 330ms 延時(shí)的數(shù)據(jù)測(cè)試：

如果設(shè)置默認(rèn)延時(shí)為 240ms，overhead_elements 第一次被調(diào)整了 -60 個(gè) block，負(fù)值表示向前查找，正好為 60 * 4 = 240ms，之后線性濾波器固定 index = 24，表示 24 * 4 = 96ms 延時(shí)，二者之和約等于 330ms。日志打印如下：

② 大延時(shí)檢測(cè) 是基于遠(yuǎn)近端數(shù)據(jù)相似性在遠(yuǎn)端大緩存中查找最相似的幀的過程，其算法原理有點(diǎn)類似音頻指紋中特征匹配的思想。大延時(shí)調(diào)整的能力是對(duì)固定延時(shí)調(diào)整與線型濾波器能力的補(bǔ)充，使用它的時(shí)候需要比較慎重，需要控制調(diào)整的頻率，以及控制造成非因果的風(fēng)險(xiǎn)。

WebRTC AEC 算法中開辟了可存儲(chǔ) 250 個(gè) block 大緩沖區(qū)，每個(gè) block 的長(zhǎng)度 PART_LEN = 64 個(gè)樣本點(diǎn)，能夠保存最新的 1s 的數(shù)據(jù)，這也是理論上的大延時(shí)能夠估計(jì)的范圍，絕對(duì)夠用了。

static const size_t kBufferSizeBlocks = 250;buffer_ = WebRtc_CreateBuffer(kBufferSizeBlocks, sizeof(float) * PART_LEN);aec->delay_agnostic_enabled = 1;

我們用 610ms 延時(shí)的數(shù)據(jù)測(cè)試(啟用大延時(shí)調(diào)整需要設(shè)置 delay_agnostic_enabled = 1)：

我們還是設(shè)置默認(rèn)延時(shí)為 240ms，剛開始還是調(diào)整了 -60 個(gè) block，隨后大延時(shí)調(diào)整接入之后有調(diào)整了 -88 個(gè) block，一共調(diào)整(60 + 88) * 4 = 592ms，之后線性濾波器固定 index = 4，表示最后剩余延時(shí)剩余 16ms，符合預(yù)期。

③ 線性濾波器延時(shí)估計(jì) 是固定延時(shí)調(diào)整和大延時(shí)調(diào)整之后，濾波器對(duì)當(dāng)前遠(yuǎn)近端延時(shí)的最直接反饋。前兩者調(diào)整不當(dāng)會(huì)造成延時(shí)過小甚至非因果，或延時(shí)過大超出濾波器覆蓋能力，導(dǎo)致無法收斂的回聲。因此前兩者在調(diào)整的過程中需要結(jié)合濾波器的能力，確保剩余延時(shí)在濾波器能夠覆蓋的范圍之內(nèi)，即使延時(shí)小范圍抖動(dòng)，線性部分也能自適應(yīng)調(diào)整。

WebRTC AEC 存在的問題：

（1）線性部分收斂時(shí)間較慢，固定步長(zhǎng)的 NLMS 算法對(duì)線性部分回聲的估計(jì)欠佳；

（2）線性部分濾波器階數(shù)默認(rèn)為 32 階，默認(rèn)覆蓋延時(shí) 132ms，對(duì)移動(dòng)端延時(shí)較大設(shè)備支持不是很好，大延時(shí)檢測(cè)部分介入較慢，且存在誤調(diào)導(dǎo)致非因果回聲的風(fēng)險(xiǎn)；

（3）基于相干性的幀狀態(tài)依賴嚴(yán)格的固定門限，存在一定程度的誤判，如果再去指導(dǎo)非線性部分抑制系數(shù)的調(diào)節(jié)，會(huì)帶來比較嚴(yán)重的雙講抑制。

優(yōu)化的方向：

（1）算法上可以通過學(xué)習(xí) speex 和 AEC3 的線性部分，改善當(dāng)前線性濾波效果；

（2）算法上可以優(yōu)化延時(shí)調(diào)整策略，工程上可以新增參數(shù)配置下發(fā)等工程手段解決一些設(shè)備的延時(shí)問題；

（3）另外，有一些新的思路也是值得我們嘗試的，如開頭提到的，既然回聲也可以是視為噪聲，那么能否用降噪的思路做回聲消除呢，答案是可以的 。

作者:珞神

來源:微信公眾號(hào):視頻云技術(shù)

出處:https://mp.weixin.qq.com/s/iq6EWCQHoYTtAwZBzs8tYA