本文講的回聲（Echo）是指語音通信時產(chǎn)生的回聲，即打電話時自己講的話又從對方傳回來被自己聽到。回聲在固話和手機上都有，小時還可以忍受，大時嚴重影響溝通交流，它是影響語音質(zhì)量的重要因素之一。可能有的朋友要問了，為什么我打電話時沒有聽見自己的回聲，那是因為市面上的成熟產(chǎn)品回聲都被消除掉了。

回聲分為線路回聲（line echo）和聲學(xué)回聲（acoustic echo），線路回聲主要存在于固話中，是由于2-4線轉(zhuǎn)換引入的回聲，聲學(xué)回聲是由于空間聲學(xué)反射產(chǎn)生的回聲 。回聲消除（Echo canceller, EC）是語音前處理的重要環(huán)節(jié)，下面主要講其基本原理和調(diào)試中的一些經(jīng)驗。

1、基本原理

1）自適應(yīng)濾波器和自適應(yīng)算法

一般濾波器的系數(shù)是固定的，而自適應(yīng)濾波器的系數(shù)是變化的，是依據(jù)自適應(yīng)算法來調(diào)整濾波器系數(shù)的。自適應(yīng)濾波器的結(jié)構(gòu)采用FIR或IIR均可，由于IIR存在穩(wěn)定性問題，因此一般采用FIR。

下圖是自適應(yīng)濾波器的一般結(jié)構(gòu)：

上圖中，x(k)為輸入信號，y(k)為輸出信號，d(k)為期望信號，e(k)是d(k)和y(k)的誤差信號。自適應(yīng)濾波器的濾波器系數(shù)受誤差信號e(k)控制，根據(jù)e(k)的值和自適應(yīng)算法自動調(diào)整。

自適應(yīng)算法一般采用LMS(least mean square，最小均方)算法及其變種（如NLMS算法）。LMS算法是隨機梯度算法族中的一員。具體可以看相關(guān)的文章。

2）回聲消除基本原理。

下圖是回聲消除基本原理的框圖：

處理過程如下：

a) 算近端遠端語音數(shù)據(jù)的energy，確定雙方是silent還是talk。

b) 遠端輸入經(jīng)過自適應(yīng)FIR濾波器后就得到了近似于近端輸入的數(shù)據(jù)，并與近端輸入相減后得到了誤差e。誤差e作為自適應(yīng)LMS算法的輸入在需要的時候去更新自適應(yīng)FIR濾波器的系數(shù)給后面遠端數(shù)據(jù)處理用。在需要的時候是指遠端talk近端silent的情況，其他情況（比如double silent / double talk）下不需要更新FIR濾波器的系數(shù)。

c) 誤差e同時也會經(jīng)過NLP（非線性處理）后產(chǎn)生舒適噪聲送給對方。

2、調(diào)試

EC相對較難，要做的很好很不容易。在webRTC開源前主要是大公司和專業(yè)的算法公司有好的實現(xiàn)方案，一般公司要想產(chǎn)品里有EC就去買算法庫。webRTC開源后一些核心的算法（包括AEC/ANS/AGC等）也隨之開源，這樣眾公司開始用webRTC里的算法，尤其是互聯(lián)網(wǎng)公司，AEC等算法基本都是用的webRTC的。

本人有兩次EC的調(diào)試經(jīng)歷。第一次是在芯片公司，做語音解決方案。從公司的算法部門拿來了回聲消除實現(xiàn)，把它用到解決方案中。另一次是在移動互聯(lián)網(wǎng)公司，做實時語音通信類APP，要把webRTC的AEC用到APP中。第一次花的時間較多，要學(xué)習(xí)原理，看算法代碼，做應(yīng)用程序驗證算法并且要修改系數(shù)，在產(chǎn)品上調(diào)試等。第二次有了第一次的基礎(chǔ)再加上webRTC封裝的較好從而花的時間較短。個人覺得對EC零基礎(chǔ)但已有EC算法代碼的基礎(chǔ)上去調(diào)試主要有如下幾步：

1）學(xué)習(xí)回聲消除的基本原理，涉及信號處理知識（從固定系數(shù)濾波器到系數(shù)自適應(yīng)濾波器）和高等數(shù)學(xué)知識（梯度）等。因為不是做算法，掌握基本的就可以了。如果基礎(chǔ)扎實，當(dāng)然搞得越明白越好了。

2）看算法代碼。如果有實現(xiàn)的設(shè)計文檔那是最好了，好多算法實現(xiàn)有技巧，有設(shè)計文檔的話能更好的幫助理解代碼。沒有只能硬著頭皮啃了。剛開始可能有些看不懂，多看幾遍，也許每一次都會多懂一些。

3）做個應(yīng)用程序驗證算法。這個應(yīng)用程序輸入是近端和遠端的PCM文件，把EC的輸出寫進一個PCM文件里，看處理效果如何。這里面也可以分幾小步：

a) 設(shè)latency為零，近端和遠端的PCM文件相同，理論上輸出是全零數(shù)據(jù)。如果是這樣，恭喜你選擇的算法有一個好的base。如果不是那就需要去調(diào)算法里的一些系數(shù)了，這也許要調(diào)好多次，最終調(diào)試結(jié)果要是算法輸出基本聽不見回聲。

b) 設(shè)一定的latency，近端的PCM和遠端的數(shù)據(jù)一樣，但是近端的PCM數(shù)據(jù)相對遠端的有一定的delay，這個值跟設(shè)定的latency值是一樣的，這時理論上輸出還是全零數(shù)據(jù)。

c) 獲取實際產(chǎn)品上的近端和遠端PCM數(shù)據(jù)，可以近似得到近端和遠端的latency。把這幾個作為輸入，看算法輸出，也要基本聽不見回聲。這步調(diào)好后算法基本上就可以用了。

4）在具體硬件平臺上去調(diào)。每個硬件平臺上的latency都是不一樣的。在芯片公司時有demo板，每個客戶也有他們的電路板，硬件平臺相對不多一個個獲取近遠端PCM數(shù)據(jù)調(diào)好latency就可以了。在移動互聯(lián)網(wǎng)公司做APP時，手機類型眾多，用上面方法太累，于是在UI上做了一個滑動條去配置latency，讓測試人員去測試找到一個相對較好的latency，然后放在配置文件里保存下來，以后這款手機就用這個latency值了。

經(jīng)過上面幾步后在真正產(chǎn)品上的EC調(diào)試就算結(jié)束了。