1. 程式人生 > >音訊處理之回聲消除及除錯經驗

音訊處理之回聲消除及除錯經驗

本文講的回聲(Echo)是指語音通訊時產生的回聲,即打電話時自己講的話又從對方傳回來被自己聽到。回聲在固話和手機上都有,小時還可以忍受,大時嚴重影響溝通交流,它是影響語音質量的重要因素之一。可能有的朋友要問了,為什麼我打電話時沒有聽見自己的回聲,那是因為市面上的成熟產品回聲都被消除掉了。回聲分為線路回聲(line echo)和聲學回聲(acoustic echo),線路回聲主要存在於固話中,是由於2-4線轉換引入的回聲,聲學回聲是由於空間聲學反射產生的回聲 。回聲消除(Echo canceller, EC)是語音前處理的重要環節,下面主要講其基本原理和除錯中的一些經驗。

1,基本原理

1)自適應濾波器和自適應演算法

一般濾波器的係數是固定的,而自適應濾波器的係數是變化的,是依據自適應演算法來調整濾波器係數的。自適應濾波器的結構採用FIR或IIR均可,由於IIR存在穩定性問題,因此一般採用FIR。下圖是自適應濾波器的一般結構:

                                                                

上圖中,x(k)為輸入訊號,y(k)為輸出訊號,d(k)為期望訊號,e(k)是d(k)和y(k)的誤差訊號。自適應濾波器的濾波器係數受誤差訊號e(k)控制,根據e(k)的值和自適應演算法自動調整。

自適應演算法一般採用LMS(least mean square,最小均方)演算法及其變種(如NLMS演算法)。LMS演算法是隨機梯度演算法族中的一員。具體可以看相關的文章。

2)回聲消除基本原理。

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

                                                                  

處理過程如下:

a)     算近端遠端語音資料的energy,確定雙方是silent還是talk。

b)    遠端輸入經過自適應FIR濾波器後就得到了近似於近端輸入的資料,並與近端輸入相減後得到了誤差e。誤差e作為自適應LMS演算法的輸入在需要的時候去更新自適應FIR濾波器的係數給後面遠端資料處理用。在需要的時候是指遠端talk近端silent的情況,其他情況(比如double silent / double talk)下不需要更新FIR濾波器的係數。

c)     誤差e同時也會經過NLP(非線性處理)後產生舒適噪聲送給對方。

2,除錯

EC相對較難,要做的很好很不容易。在webRTC開源前主要是大公司和專業的演算法公司有好的實現方案,一般公司要想產品裡有EC就去買演算法庫。webRTC開源後一些核心的演算法(包括AEC/ANS/AGC等)也隨之開源,這樣眾公司開始用webRTC裡的演算法,尤其是網際網路公司,AEC等演算法基本都是用的webRTC的。

本人有兩次EC的除錯經歷。第一次是在晶片公司,做語音解決方案。從公司的演算法部門拿來了回聲消除實現,把它用到解決方案中。另一次是在移動網際網路公司,做實時語音通訊類APP,要把webRTC的AEC用到APP中。第一次花的時間較多,要學習原理,看演算法程式碼,做應用程式驗證演算法並且要修改係數,在產品上除錯等。第二次有了第一次的基礎再加上webRTC封裝的較好從而花的時間較短。個人覺得對EC零基礎但已有EC演算法程式碼的基礎上去除錯主要有如下幾步:

1)學習回聲消除的基本原理,涉及訊號處理知識(從固定係數濾波器到係數自適應濾波器)和高等數學知識(梯度)等。因為不是做演算法,掌握基本的就可以了。如果基礎紮實,當然搞得越明白越好了。

2)看演算法程式碼。如果有實現的設計文件那是最好了,好多演算法實現有技巧,有設計文件的話能更好的幫助理解程式碼。沒有隻能硬著頭皮啃了。剛開始可能有些看不懂,多看幾遍,也許每一次都會多懂一些。

3)做個應用程式驗證演算法。這個應用程式輸入是近端和遠端的PCM檔案,把EC的輸出寫進一個PCM檔案裡,看處理效果如何。這裡面也可以分幾小步:

a)     設latency為零,近端和遠端的PCM檔案相同,理論上輸出是全零資料。如果是這樣,恭喜你選擇的演算法有一個好的base。如果不是那就需要去調演算法裡的一些係數了,這也許要調好多次,最終除錯結果要是演算法輸出基本聽不見回聲。

b)    設一定的latency,近端的PCM和遠端的資料一樣,但是近端的PCM資料相對遠端的有一定的delay,這個值跟設定的latency值是一樣的,這時理論上輸出還是全零資料。

c)    獲取實際產品上的近端和遠端PCM資料,可以近似得到近端和遠端的latency。把這幾個作為輸入,看演算法輸出,也要基本聽不見回聲。這步調好後演算法基本上就可以用了。

4)  在具體硬體平臺上去調。每個硬體平臺上的latency都是不一樣的。在晶片公司時有demo板,每個客戶也有他們的電路板,硬體平臺相對不多一個個獲取近遠端PCM資料調好latency就可以了。在移動網際網路公司做APP時,手機型別眾多,用上面方法太累,於是在UI上做了一個滑動條去配置latency,讓測試人員去測試找到一個相對較好的latency,然後放在配置檔案裡儲存下來,以後這款手機就用這個latency值了。

經過上面幾步後在真正產品上的EC除錯就算結束了。