火山引擎 RTC 音訊 AI 降噪的應用與實踐

語言: CN / TW / HK

動手點關注 乾貨不迷路  :point_up_2:

從視訊會議到遠端醫療,從連麥開黑到陪伴社交,疫情常態化加速了線下活動線上化,逐漸改變了人們的生產生活方式。其中,音訊質量很大程度上影響著通話體驗,而噪聲又很大程度決定音訊質量。比如,居家辦公場景,就流傳著“居家辦公,必有鄰居裝修”的定律。也是因為裝修聲會很大程度影響參與效率,所以對居家辦公的同學帶來了很大的影響。火山引擎 RTC,集成了自研的深度學習降噪方案,來應對遊戲、互娛、會議等實時音視訊溝通場景下的噪聲影響。

讓我們看一下 RTC AI 降噪在會議、 遊戲、 居家場景下的降噪效果對比。

會議場景

遊戲場景

居家場景

通過上面的對比效果可以明顯看到不同噪聲對線上生產、生活場景的影響,以及通過 AI 降噪達到的降噪效果。RTC AI 音訊降噪採用了經典的CRN網路結構【 參考文獻  1】作為降噪框架。CRN 網路結構由 Encoder、Recurrent Layer 和 Decoder 三部分組成。這種結構兼具了 CNN 的深層特徵抽取能力和遞迴網路的記憶能力,表現出了比純 CNN 網路或者純 GRU 網路更好的降噪能力。

CRN網路結構

在具體落地到產品的過程中,我們在上述基礎模型中,解決了實際場景中出現的五大問題:

  1. 如何應對各種複雜的裝置,多樣的環境

  2. 如何在滿足低延時條件下,提升模型效果

  3. 如何在滿足低計算量條件下,提升模型效果

  4. 如何平衡強降噪和高保真

  5. 如何應對對音樂的損傷

通過解決上述問題,可以有效提升演算法的速度、實時性和穩定性,保證在語音無損傷的情況下最大程度地實現噪聲抑制,提升實時音視訊場景,特別是會議、音樂等複雜場景下的互動體驗。下面具體展開講下我們是分別如何解決上述五大問題的。

一、訓練資料增廣

在我們實際生活中,降噪演算法所需要面臨的 場景是非常複雜多樣 的。

拿“會議”場景舉例,開會環境的多樣性給降噪演算法帶來了不少挑戰:在座位上開會,裝置會採集到鄰座工位上的說話聲,此時我們期望演算法能去除一定的背景說話人聲;在會議室中開會,由於說話人離麥克風的距離各不相同,此時降噪演算法面臨著多人聲、遠距離拾音、混響的難題;如果是在公交、地鐵、高鐵上開會,除了人聲,還會引入車輛訊號、報站等聲音。還有比如在室內玩遊戲使用遊戲語音的例子,此時,場景中的噪聲除了環境噪聲,還有敲擊螢幕或鍵盤、拍桌子等各類噪聲,此時就需要降噪演算法能夠儘量抑制足夠多類別的噪聲。

不僅如此,在不同環境下常用的裝置也是不盡相同的。常用裝置主要可以歸類為以下幾類:

除了使用場所有所差別,另外一個主要差異點在於不同裝置的採集特性不同,並且自帶了不同的音訊前處理演算法,以現在主流的安卓手機為例,往往出廠就自帶了強抑制降噪演算法,但在實際體驗中仍然存在噪聲較多以及人聲損傷問題,那麼就需要我們的降噪演算法去適配這一類“二手”音訊資料,包括需要去覆蓋殘留形態的噪聲資料,以及損傷形態的人聲資料。

除此之外,個人外接裝置也需要特別小心,比如有線耳機可能會帶來高頻噪聲,而藍芽耳機可能引入連線不穩定的問題,並且降噪耳機還攜帶有額外的音訊處理能力。

下為耳機雜音噪聲降噪前後的表現。

我們將在資料增廣過程中著重應對這類問題。將增廣中噪聲的型別打上標籤、對不同的場景使用不同的增廣配置檔案即可配置不同的訓練增廣方案。下面簡單說明一下我們常用的訓練資料增廣手段。

基本增 手段 包括:

  • 音量調整:現實生活中採集到的音量大小往往不同,用於模擬不同採集音量的情況;

  • 高低通濾波:不同裝置的有效頻率不同,如藍芽耳機往往只有 4k 的有效頻段;

  • 削波模擬:模擬爆音之後的音訊效果;

  • 房間衝擊響應:模擬不同房間下的混響場景;

  • 破音訊號模擬:增加對丟幀訊號的模擬

  • 模擬噪聲變化:模擬不同噪聲環境,如常見場景的噪聲疊加和變化;

我們近期針對語音中的嘯叫訊號著重進行了模擬和處理。通過線下采集,以及線上模擬模擬的方式生成了大量的不同嘯叫週期、頻率範圍的嘯叫語音,並以較低的信噪比融合進原始語音中。

嘯叫語音線上模擬

在增加了上述嘯叫資料的基礎上,我們又單獨對嘯叫語音施加強抑制的損失函式,消除了大部分的嘯叫語音。

我們測試了各種裝置、各種場景下的 500+ 種噪聲,均能實現理想的消除效果。

二、壓縮模型計算量

實時率 (Real Time Factor) 是衡量演算法的 CPU 消耗的指標。實時通訊下場景,對模型算力要求極為苛刻。為了讓模型在移動端可流暢執行,我們主要在特徵壓縮、模型精簡和引擎加速三個方面進行了改進。

(1) 特徵壓縮

在原始的 CRN 的文章中,使用的是短時傅立葉 (STFT) 特徵,如 WebRTC 中預設使用的 257 維的 STFT 特徵。但是 STFT 在高頻處包含的資訊量已經較少,根據人耳聽覺特性進行頻譜壓縮已經是常見的方案,如 RNNoise 中使用 ERB 方案。我們採用根據梅爾聽覺特性設計的濾波器進行頻譜壓縮的方案。

通過將高維特徵壓縮到低維,能將計算量壓縮為原來的 1/3。

(2) 模型精簡

如前文所述,我們使用了 CRN 結構作為主要的結構。為了將整體的模型的計算量進行進一步的壓縮,我們嘗試了很多的策略,主要包括:

  • 將其中的卷積或者轉置卷積模組替換為深度可分離卷積或者可分離轉置卷積

  • 使用空洞卷積,使用更少層數能夠獲得更長的感受野

  • 將 GRU 模組替換為分組 GRU 模組

  • 使用稀疏化工具,進一步壓縮通道數的大小

通過上述一系列優化,模型的計算量被壓縮到數十兆 MACS 的計算量級,模型的引數量在 100K 以內。

(3) 引擎加速

最後我們在位元組跳動的推理引擎 ByteNN 上,與智創語音團隊和 AI 平臺團隊合作,新增了適配音訊演算法的流式推理能力,來提升裝置上的計算效率。主要包括:

  • 架構支援子圖推理 / 提前退出等流式推理能力節省算力

  • 包括卷積 / GRU 等流式運算元的支援

  • ARM / X86 等平臺彙編級別優化加速

通過上述手段,目前將端到端的 48K 降噪模型的 RTF 指標在各端機型上都控制在 1% 以內。

三、降低延時

為了保證端到端延時在較低水平,AINR 直接使用 AEC 輸出的頻域特徵作為輸入,減少了一次 ISTFT 和一次 STFT 的計算時間以及引入的(窗長-步長)的延時(一般在 20ms 左右)。然而在實驗中我們發現,由於 AEC 的非線性處理的操作是直接在頻譜的操作,導致了 STFT 的不一致性,即原始的 STFT 經過 ISTFT 後再做 STFT 的值與原始值不一致。所以直接使用 AEC 的頻域輸出(頻域特徵 1 )作為模型的輸入和使用頻域特徵 2 作為模型輸入的處理結果略有不同,前者在個別場景會出現語音損傷。

我們通過一系列的工程手段,解決了這種不一致性,使得處理過程可以繞過上述的 ISTFT 和 STFT 過程,節省了 20 毫秒以上的時間。如此節省下來的時間,可用於增加模型的延時,但保證系統的總體延時不會增加。增加模型的延時對區分清子音和噪音有很大的幫助。如左、中例子所示,清子音在頻譜和聽感上和噪聲十分接近,在不知道下文的情況下模型很難做出準確的判斷。於是我們引入 20~40ms 不等的較短延時,利用未來的資訊幫助模型做當前幀的判斷,如右例子所示,加入延時後的非語音段要明顯比優化前乾淨。

加入 延時 ,噪音消除能力提升

四、降噪與保真的平衡

降噪效果中,強降噪和高保真往往是天平的兩端,尤其是針對小模型。強力的降噪往往會帶來部分語音的損傷,對語音高保真往往會殘留部分的小噪聲。比如,在針對 babble 的降噪實驗過程中發現,如果採用強力降噪模型,能夠把辦公室的 babble 類噪聲都消除的很乾淨,但是針對會議室的遠場語音就會帶來損傷。為了平衡這兩者,我們主要採取瞭如下的一些策略來改進:

  1. 剔除噪聲髒樣本:去掉包含“說話聲”的噪聲樣本,避免噪聲中包含內容清晰的語音,導致推理時將遠場人聲誤判為噪聲。

  2. 輸入特徵進行幅度規整:保證不同幅度的語音提取的特徵值是非常接近的,剔除幅度的影響。

  3. 在靜音段部分使用抑制力度大的損失函式,而在人聲部分使用保護力度更大的損失函式。來保證非語音段強降噪、而語音段高保真的目的。

  4. 針對小語音段,在計算損失函式時提升對於語音有損的懲罰力度。

我們以輕微帶噪語音的 PESQ 指標作為語音保真的指標。以純噪部分的殘留噪聲平均分貝作為噪聲抑制的指標。下表列出了幾次迭代在會議場景下的指標改進。

第一版

第二版

第三版

語音保留

3.72

3.76

3.85

噪聲殘留(dB)

-75.88

-105.99

-111.03

從幾個版本降噪模型的客觀指標來看,語音保護指標在較小的範圍內波動,噪聲殘留則不斷減少。可以看出 RTC AI 降噪模型在較大程度保護語音的前提下,噪聲抑制力度不斷提升。

五、實時音樂識別

在互娛場景,往往有較多的音樂場景。由於部分音樂元素和噪聲的特點非常接近,如果直接應用深度學習降噪模型,音樂會被壓制得很卡頓。如果把音樂保護加入模型訓練,其他語料中的噪聲壓制的效果會受到影響。因此,準確識別出聲音是音樂還是噪聲就變得非常重要,能在識別出音樂之後關閉降噪,同時也不會影響正常場景下的降噪力度。

我們的音樂識別模型和【參考文獻 2】方法非常相似。都是在 PANNS 【 參考文獻  3】的 527 類語音檢測的基礎上,使用語音、音樂和噪聲三類資料進行微調。考慮這類方法的一個主要原因是利用 CNN 對長時語音(4 秒窗長)進行建模,以 0.33 秒為步長輸出判別結果,來代替如 GRU 類模型幀級別的輸出,從而增強識別的效果和穩定性。相對於原文,我們進一步對模型進行了壓縮和裁剪,達到了 4M  FLOPS 的計算量 和 20KB 的引數量的尺寸,保證在低端的移動裝置上可以執行。同時,在進入音樂時,增加 2 秒延時的多幀融合判斷以及離開音樂時 4 秒延時的多幀融合判斷,進一步提升了音樂識別的穩定性。在音樂誤識別率為 0% 的情況下,召回率達到了 99.6%。

下圖展示了 SIP 場景下的音樂共享場景的一個例子。因為 SIP 場景下,共享音樂和採集訊號是混合後再傳輸的,所以共享的訊號和採集的訊號使用的是同樣的處理通路。在實際測試中,我們發現即使用很輕量級的傳統降噪方案也會對音樂產生損傷。通過使用音樂檢測,保護相對應的音樂段,可以有效緩解該損傷問題。

六、

效果和指標

的對比

通過上述幾點的改進,目前無論是主觀聽感,還是客觀指標,火山引擎 RTC 中的降噪演算法已經處於行業領先位置。

我們在高中低三種信噪比條件的白噪聲、鍵盤聲、babble 噪聲、空調噪聲四種噪聲環境下以及 Windows 和 MAC 裝置中,測試了火山引擎 RTC 和行業同類產品的降噪結果的 POLQA 分數。從表中可以看出,無論是在這四種噪聲場景上,還是在不同裝置上,我們的降噪演算法均優於同類產品。

在應用 AI 降噪之後,我們能夠消除環境噪聲帶來的各種影響。但除了噪聲影響之外,影響語音質量的還包括採集硬體的損傷、硬體處理演算法的損傷、傳輸通道的損傷等等,後續我們會進一步在軟體演算法中緩解這些損傷,以期達到使用任何硬體均能達到類似錄音棚的高音質效果。

參考文獻

【1】Tan K, Wang D L. A convolutional recurrent neural network for real-time speech enhancement[C]//Interspeech. 2018, 2018: 3229-3233.

【2】Reddy C K A, Gopa V, Dubey H, et al. MusicNet: Compact Convolutional Neural Network for Real-time Background Music Detection[J]. arXiv preprint arXiv:2110.04331, 2021.

【3】Kong Q, Cao Y, Iqbal T, et al. Panns: Large-scale pretrained audio neural networks for audio pattern recognition[J]. IEEE/ACM Transactions on Audio, Speech, and Language Processing, 2020, 28: 2880-2894.

關於我們

火山引擎 RTC 團隊,作為全球領先的音視訊團隊,我們致力於提供全球網際網路範圍內高品質、低延時的實時音視訊通訊能力,目前已經支撐了抖音、TikTok、清北網校、位元組系遊戲,視訊會議等多個場景的應用,服務 10 億使用者,遍佈全球每一個角落。

我們是 RTC Lab 部門,負責 RTC 產品中音訊、視訊、網路等基礎功能的研發,通過極致的工程和音視訊演算法,打磨頂級的實時音視訊基礎體驗,期待優秀同學的加入!

:runner: 掃描上方二維碼,或點選 閱讀原文 ,趕緊加入我們吧!