在實時音頻互動場景中，除了我們上一篇講到的編解碼會影響音質與體驗，在端上，降噪、回聲消除、自動增益子產品同樣起着重要作用。在本篇内容中我們将主要圍繞回聲消除和降噪子產品，講講實時互動場景下的技術挑戰，以及我們的解決思路與實踐。「文末有個小彩蛋:) 」
回聲消除的三大算法子產品優化
在語音通信系統中，回聲消除（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