低延時、高音質語音通話背後的音頻技術解析——降噪與回聲消除篇

在實時音頻互動場景中，除了咱們上一篇講到的編解碼會影響音質與體驗，在端上，降噪、回聲消除、自動增益模塊一樣起着重要做用。在本篇內容中咱們將主要圍繞回聲消除和降噪模塊，講講實時互動場景下的技術挑戰，以及咱們的解決思路與實踐。

回聲消除的三大算法模塊優化

在語音通訊系統中，回聲消除（Echo Cancellation）一直扮演着核心算法的角色。通常來講，回聲消除的效果受諸多因素的影響，包括： 聲學環境，包括反射，混響等；

• 通話設備自己聲學設計，包括音腔設計以及器件的非線性失真等；

• 系統性能，處理器的計算能力以及操做系統線程調度的能力。

聲網回聲消除算法在設計之初，就將算法性能、魯棒性和普適性做爲最終的優化目標，這一點對於一個優秀的音視頻 SDK 來講相當重要。

首先，回聲是怎麼產生的？簡單來說，就是你的聲音從對方的揚聲器發出，這個聲音又被他的麥克風給收錄了進去，這個被麥克風收錄的聲音又傳回到你這一端，你就聽到了回聲。爲了消除回聲，咱們就要設計一個算法將這個聲音信號從麥克風信號中去除掉。

那麼聲學回聲消除模塊（AEC, Acoustic Echo Cancellation）是如何消除回聲的呢？具體的步驟見以下簡圖所示：

• 第一步須要找到參考信號/揚聲器信號（藍色折線）跟麥克風信號（紅色折線）之間的延遲，也就是圖中的 delay=T。

• 第二步根據參考信號估計出麥克風信號中的線性回聲成分，並將其從麥克風信號中減去，獲得殘差信號（黑色折線）。

• 第三步經過非線性的處理將殘差信號中的殘餘回聲給完全抑制掉。

與以上的三個步驟相對應，回聲消除也由三個大的算法模塊組成：

• 延遲估計（Delay Estimation）

• 線性自適應濾波器（Linear Adaptive Filter）

• 非線性處理（Nonlinear Processing）

其中「延遲估計」決定了AEC的下限，「線性自適應濾波器」決定了 AEC 的上限，「非線性處理」決定了最終的通話體驗，特別是回聲抑制跟雙講之間的平衡。

注：雙講是指在交互場景中，互動雙方或多方同時講話，其中一方的聲音會受到抑制，從而出現斷斷續續的狀況。這是因爲回聲消除算法「矯枉過正」，消除了部分不應去除的音頻信號。

接下來，咱們先圍繞這三個算法模塊，分別講講其中的技術挑戰與優化思路。

1、延遲估計

受具體系統實現的影響，當把參考信號與麥克風信號分別送入 AEC 模塊進行處理之時，它們所存入的數據 buffer 之間存在一個時間上的延遲，即咱們在上圖中看到的「delay=T」。假設這個產生回聲的設備是一部手機，那麼聲音從它的揚聲器發出後，一部分會通過設備內部傳導到麥克風，也可能會通過外部環境傳回到麥克風中。因此這個延遲就包含了設備採集播放 buffer 的長度，聲音在空氣中傳輸的時間，也包含了播放線程與採集線程開始工做的時間差。正是因爲影響延遲的因素不少，所以這個延遲的值在不一樣系統，不一樣設備，不一樣 SDK 底層實現上都各不相同。 它在通話過程當中也許是一個定值，也有可能會中途變化（所謂的 overrun 和 underrun）。這也是爲何一個 AEC 算法在設備 A 上可能起做用，但換到另外一個設備上可能效果會變差。延遲估計的精確性是 AEC 可以工做的先決條件，過大的估計誤差會致使 AEC 的性能急劇降低，甚至沒法工做，而沒法快速跟蹤時延變化是出現偶現回聲的重要因素。

加強延遲估計算法魯棒性

傳統算法一般經過計算參考信號跟麥克風信號之間的相關性來決定延遲。相關性的計算能夠放在頻域上，典型的就是 Binary Spectrum 的方法，經過計算單頻點上的信號能量是否超過必定門限值，實際將參考信號跟麥克風信號映射成了兩維的0/1數組，而後經過不斷移動數組偏移來找到延遲。最新的 WebRTC AEC3 算法經過並行的多個NLMS線性濾波器來尋找延遲，這個方法在檢測速度及魯棒性方面都取得了不錯的效果，可是計算量很是大。當在時域上計算兩個信號的互相關時，一個明顯的問題是語音信號包含大量的諧波成分而且具備時變特性，它的相關信號經常呈現出多峯值的特徵，有的峯值並不表明真正的延遲，而且算法容易受到噪聲干擾。

聲網延遲估計算法經過下降信號之間的相關性（de-correlate），可以有效抑制 local maxima 的值以大大加強算法的魯棒性。以下圖所示，左邊是原始信號之間的互相關，右邊是聲網SDK處理後的互相關，可見信號的預處理大大加強了延遲估計的魯棒性：

算法自適應，下降計算量

一般延遲估計算法爲了下降計算量的須要，會預先假設回聲信號出如今某個較低的頻段內，這樣就能夠將信號作完下采樣以後再送入延遲估計模塊，下降算法的計算複雜度。然而面對市面上數以萬計的設備及各類路由，以上的假設每每並不成立。下圖是 VivoX20 在耳機模式下麥克風信號的頻譜圖，可見回聲都集中在 4kHz 以上的頻段內，傳統的算法針對這些 case 都會致使回聲消除模塊的失效。聲網延遲估計算法會在全頻段內搜索回聲出現的區域，並自適應地選擇該區域計算延遲，確保算法在任何設備，路由下都有精確的延遲估計輸出。

動態更新音頻算法庫，提高設備覆蓋率

爲了確保算法的持續迭代改進，聲網維護了一個音頻算法的數據庫。咱們使用大量不一樣測試設備，在不一樣聲學環境下采集到了各類參考信號和麥克風信號的組合，而它們之間的延遲所有經過離線處理的方式進行標定。除了真實採集的數據，數據庫中也包含了大量仿真的數據，包括不一樣的說話人，不一樣的混響強度，不一樣的底噪水平，以及不一樣的非線性失真類型。爲了衡量延遲估計算法的性能，參考信號與麥克風信號之間的延遲能夠隨機的變化，用以觀察算法對突發延遲變化的響應。

因此判斷一個延遲估計算法的優劣，還須要考察：

1. 適應儘可能多的設備、聲學環境，且在儘可能短的時間內根據設備、聲學環境的因素匹配合適的算法；

2. 在突發隨機的延遲變化後，能及時動態調整算法策略。

如下是聲網 SDK 與友商之間的延遲估計性能對比，總共使用了數據庫中 8640 組測試數據。從圖中數據能夠看出，聲網 SDK 能夠在更短的時間內找到大多數測試數據的初始時延。在 96% 的測試數據中，聲網 SDK 能在 1s 以內找到它們正確的延遲，而友商這一比例爲 89%。

第二個測試的是在通話過程當中出現隨機的延遲抖動，測試延遲估計算法要在儘可能短的時間內找到精確的延遲值。如圖中所示，聲網 SDK 在 71% 的測試數據中能在 3s 以內從新找到變化後的精確延遲值，而友商這個比例爲 44%。

2、線性自適應濾波器

對於線性濾波器，已有大量的文獻介紹其原理及實踐。當應用於回聲消除的應用場景，主要考慮的指標包含收斂速度（convergence rate），穩態失調（steady-state misalignment）及跟蹤性能（tracking capability）。這些指標之間每每也有衝突，譬如較大的步長能夠改善收斂速度，可是會致使較大的失調。這個就是自適應濾波器中的沒有免費的午飯定理(No Free Lunch Theorem)。

對於自適應濾波器的類型，除了最爲經常使用的 NLMS 濾波器（Model Independent），還可使用 RLS 濾波器（Least Squares Model）或 Kalman 濾波器（State-Space Model）。除了各自理論推導中的各類假設，近似，優化，這些濾波器的性能最終都歸結到如何計算最佳的步長因子（在卡爾曼濾波器裏面步長因子合併到 Kalman Gain 的計算裏面）。在濾波器還沒有收斂或是環境傳輸函數突變的情形下，步長因子須要足夠大以跟蹤環境變化，當濾波器收斂及環境傳遞函數變化緩慢的時間段，步長因子應儘可能減少以達到儘量小的穩態失調。對於步長因子的計算，須要考慮自適應濾波器後殘餘回聲跟殘差信號間的能量比值，建模爲系統的 leakage coefficients。這個變量經常等價於求濾波器係數跟真實傳遞函數之間的差（Kalman 濾波器裏面稱爲狀態空間狀態向量偏差），這也是整個估計算法中的難點。除此以外，雙講階段的濾波器發散問題也是一個須要考慮的點，通常來講這個問題能夠經過調整濾波器結構，使用 two echo path models 來解決。

聲網自適應濾波器算法並不使用單一的濾波器類型，而是兼顧了不一樣濾波器之間的優勢，同時搭配自適應算法計算最優的步長因子。此外，算法經過線性濾波器係數實時估計環境的傳遞函數，自動修正濾波器長度，以覆蓋通訊設備鏈接 HDMI 外設等高混響，強回聲的場景。以下是一個例子，在聲網辦公室的一箇中型會議室中（面積約 20m2，三面玻璃牆），使用 Macbook Pro 經過 HDMI 鏈接小米電視，圖中是線性濾波器時域信號的變化趨勢，算法能自動計算並匹配實際環境傳遞函數的長度（在第 1400 幀左右自動檢測出了強混響環境），以優化線性濾波器的性能。

一樣的，咱們也使用數據庫中大量測試數據進行聲網 SDK 與友商之間的性能對比，對比的指標包括穩態失調（濾波器收斂以後對回聲的抑制程度）以及收斂速度（濾波器達到收斂狀態須要的時長）。第一張圖表明自適應濾波器的穩態失調，聲網SDK在 47%的測試數據中能達到超過 20dB 的回聲抑制，而友商的比例爲 39%。

下圖顯示的是自適應濾波器的收斂速度，聲網 SDK 在 51% 的測試樣本中能在通話前 3s 以內收斂到穩態，而友商的比例爲13%。

3、非線性處理

非線性處理旨在抑制線性濾波器所沒有預測出的回聲成分，一般經過計算參考信號，麥克風信號，線性回聲以及殘差信號間的相關性，或是將相關性直接映射到抑制增益上，或是經過相關性估計出殘留回聲的功率譜，進一步經過維納濾波器等傳統降噪的算法抑制殘留回聲。

做爲回聲消除算法的最後一個模塊，除了抑制殘留回聲以外，非線性處理單元也肩負着監控整個系統是否正常工做的重任，譬如線性濾波器是否由於延遲抖動而沒法正常工做？在聲網 SDK 回聲消除以前是否存在硬件回聲消除未能處理的殘餘回聲？

下面是一個簡單的例子，經過自適應濾波器估計出的回聲能量等內部參數，可以更快的發現延遲變化的現象，而且提示 NLP 採起相應的動做：

隨着聲網 SDK 覆蓋的場景愈來愈廣，針對音樂信號的傳輸成爲了一個重要的場景。聲網 SDK 針對音樂信號的回聲消除體驗作了大量的優化，一個典型場景是溫馨噪聲的估計算法改進。傳統算法使用基於 Minimum Statistics 的算法原理對信號中的底噪進行估計，當把這個算法應用於音樂信號時，由於音樂信號比之語音信號更爲平穩，所以會太高的估計噪聲功率，反映到回聲消除中會致使處理後有回聲時段與無回聲時段間的底噪（背景噪聲）不平穩，體驗極差。聲網 SDK經過信號分類以及模塊融合的方式，完全解決了 CNG 估計致使的底噪起伏現象。

除此以外，聲網 SDK 還針對全部可能碰到的極端狀況，包括非因果系統，設備頻率偏移，採集信號溢出，聲卡包含系統信號處理等等，都進行了大量的優化，確保算法可以工做在全部的通訊場景中。

音質優先的降噪策略

降噪對信號音質的影響大於回聲消除模塊，這一點源自於在降噪算法的設計之初，咱們先驗的假設底噪都是平穩信號（至少是短時平穩的），而根據這個假設，音樂跟底噪的區分度明顯弱於語音跟底噪的區分度。

聲網 SDK 在降噪模塊的前端預置了信號分類模塊，可以精確的檢測出信號的類型，並根據信號的類型調整降噪算法的類型及參數，常見的信號類型包括通常語音、清唱、音樂信號等。下圖所示是兩個降噪算法處理的信號片斷，其中第一個是語音與音樂的混合信號，前15秒爲含噪的語音信號，以後是40s是音樂信號，再以後是10s的含噪語音，語譜圖從上到下分別是原始信號、友商處理結果、聲網SDK處理結果。結果顯示在語音段信號降噪性能差很少的前提下，競品處理過信號中的音樂部分受到了嚴重的損傷，而聲網SDK的處理並無下降音樂的音質。

在第二個例子中，使用的音頻是歌手的清唱，清唱中歌手反覆發出「啊」的聲音。在下圖的語譜圖中，從上到下分別是原始信號、友商的處理結果、聲網 SDK 處理結果。結果顯示，友商的降噪處理嚴重的損傷了原語音的頻譜成分，而聲網 SDK 完整的保留了原語音的諧波成分，保證了歌手清唱時候的音質體驗。

結語

自1967年貝爾實驗室的M. M. Sondhi開創性的提出以自適應濾波器的方法來消除回聲爲開端，無數的研究和實踐都投入到了這個語音通訊的最基本問題上。要完美的解決回聲問題，除了要有強大的算法做爲基礎，也須要在工程優化領域作不少優化。聲網會持續不斷的改進回聲消除在各個不一樣應用場景下的體驗。

在本系列的下一篇內容中，咱們將隨着音頻信號，從設備端進入現實的網絡環境，一邊實地環行上海，一邊聊聊音頻互動場景下的延時、抖動，以及丟包對抗背後的優化策略。（以一張圖來簡單劇透，敬請期待）