詳解低延時高音質：回聲消除與降噪篇

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

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

在語音通信系統中，回聲消除（Echo Cancellation）一直扮演着核心算法的角色。一般來說，回聲消除的效果受諸多因素的影響，包括：

• 聲學環境，包括反射，混響等；

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

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

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

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

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

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

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

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

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

• 延遲估計（Delay Estimation）

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

• 非線性處理（Nonlinear Processing）

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

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

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

一、延遲估計

受具體系統實現的影響，當把參考信號與麥克風信號分別送入 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 都會導致回聲消除模塊的失效。聲網延遲估計算法會在全頻段內搜索回聲出現的區域，並自適應地選擇該區域計算延遲，確保算法在任何設備，路由下都有精確的延遲估計輸出。

圖：VivoX20 接入耳機後的麥克風信號

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

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

所以判斷一個延遲估計算法的優劣，還需要考察：

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

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

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

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

二、線性自適應濾波器

對於線性濾波器，已有大量的文獻介紹其原理及實踐。當應用於回聲消除的應用場景，主要考慮的指標包含收斂速度（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%。

三、非線性處理

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

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

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

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

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

音質優先的降噪策略

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

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

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

結語

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

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

END

本文分享自微信公衆號 - 音視頻開發進階（glumes_blog）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。