想象一下在機場等你的航班。突然，一個重要的商務(wù)電話與一個高姿態(tài)的客戶點亮了你的手機。大量的背景噪音使你周圍的聲音變得雜亂無章——背景嘈雜，飛機起飛，也許是飛行通告。你必須接電話，而且你要聽清楚。

我們都曾處于這種尷尬、不理想的境地。這只是現(xiàn)代商業(yè)的一部分。

背景噪音無處不在。這很煩人。

現(xiàn)在想象一下，當你接電話說話時，噪音神奇地消失了，而另一端所有人能聽到的都是你的聲音。沒有聲音的低語穿過。

我們的激情代表著我們的愿景。讓我們聽聽好的降噪效果。

兩年前，我們坐下來，決定開發(fā)一種技術(shù)，可以完全消除人與人之間交流中的背景噪音，使之更加愉悅和易懂。從那時起，這個問題就成了我們的困擾。

讓我們看看是什么讓噪聲抑制如此困難，構(gòu)建實時低延遲噪聲抑制系統(tǒng)需要什么，以及深度學(xué)習(xí)如何幫助我們將質(zhì)量提升到一個新的水平。

噪聲抑制技術(shù)的現(xiàn)狀

讓我們弄清楚什么是噪音抑制。乍一看，這似乎令人困惑。

本文中的噪聲抑制是指抑制從 你的 背景到您正在通話的人的噪聲，以及來自 他們的 背景的噪聲。

這與 有源噪聲消除 相反， VZX23 指的是抑制來自周圍環(huán)境的不必要的噪音。主動噪聲消除通常需要多麥克風(fēng)耳機（如 BoseQuiteComfort ）。

這篇文章的重點是噪聲抑制， 不主動噪聲消除。

傳統(tǒng)的噪聲抑制方法

傳統(tǒng)的噪聲抑制已經(jīng)在邊緣設(shè)備上得到了有效的實現(xiàn)，如電話、筆記本電腦、會議系統(tǒng)等。這似乎是一種直觀的方法，因為它是邊緣設(shè)備，首先捕捉用戶的聲音。一旦捕獲，設(shè)備過濾掉噪音，并將結(jié)果發(fā)送到呼叫的另一端。

10 年前的手機通話體驗相當糟糕。一些移動電話仍然如此；然而，更現(xiàn)代的手機配備了多個麥克風(fēng)（ mic ），這有助于在通話時抑制環(huán)境噪音。

當前一代手機包括兩個或兩個以上的麥克風(fēng)，最新的 iPhone 有 4 個。第一個麥克風(fēng)放在手機的前底部，最靠近用戶說話時的嘴，直接捕捉用戶的聲音。手機設(shè)計師將第二個麥克風(fēng)放置在離第一個麥克風(fēng)盡可能遠的地方，通常放在手機的上背部。

兩個麥克風(fēng)都能捕捉周圍的聲音?？拷斓柠溈孙L(fēng)捕捉到更多的聲音能量；第二個麥克風(fēng)捕捉的聲音更少。軟件有效地將這些信息相互抵消，產(chǎn)生（幾乎）干凈的聲音。

這聽起來很簡單，但很多情況下都存在這種技術(shù)失敗的情況。想象一下，當這個人不說話，而麥克風(fēng)聽到的只是噪音。或者想象這個人在說話的時候，比如跑步的時候，正在積極地搖晃/轉(zhuǎn)動手機。處理這些情況很棘手。

對于設(shè)備原始設(shè)備制造商和 ODM 來說，兩個或更多的麥克風(fēng)也使得音頻路徑和聲學(xué)設(shè)計變得相當困難和昂貴。音頻/硬件/軟件工程師必須實施次優(yōu)權(quán)衡，以支持工業(yè)設(shè)計和語音質(zhì)量要求…

考慮到這些困難，今天的手機在中等噪音的環(huán)境中表現(xiàn)得相當好?，F(xiàn)有的噪聲抑制解決方案并不完美，但確實提供了改進的用戶體驗。

使用分離式話筒時，外形因素會起作用。第一個和第二個麥克風(fēng)之間的距離必須滿足最低要求。當用戶把手機放在耳朵和嘴上說話時，效果很好。

然而，現(xiàn)代手機的“棒棒糖”外形可能不會長期存在。可穿戴設(shè)備（智能手表、胸前的麥克風(fēng)）、筆記本電腦、平板電腦和 Alexa 等智能語音助手顛覆了平板手機的外形。用戶從不同的角度和不同的距離與他們的設(shè)備交談。在大多數(shù)情況下，沒有可行的解決辦法。噪音抑制只是失敗了。

從多話筒設(shè)計轉(zhuǎn)向單話筒設(shè)計

多麥克風(fēng)設(shè)計有幾個重要的缺點。

它們需要一定的外形尺寸，使其僅適用于特定的使用場合，例如帶有粘性麥克風(fēng)的電話或耳機（專為呼叫中心或入耳式監(jiān)聽器設(shè)計）。

多麥克風(fēng)設(shè)計使得音頻路徑變得復(fù)雜，需要更多的硬件和代碼。此外，為二次麥克風(fēng)鉆孔帶來了工業(yè) ID 質(zhì)量和產(chǎn)量問題。

只能在邊緣或設(shè)備側(cè)處理音頻。因此，由于低功耗和計算需求，支持它的算法并不十分復(fù)雜。

現(xiàn)在想象一個解決方案，你只需要一個麥克風(fēng)，所有的后處理都由軟件處理。這使得硬件設(shè)計更加簡單和高效。

事實證明，在音頻流中分離噪聲和人類語言是一個具有挑戰(zhàn)性的問題。此函數(shù)不存在高性能算法。

傳統(tǒng)的數(shù)字信號處理（ DSP ）算法通過逐幀處理音頻信號，不斷地尋找噪聲模式并加以適應(yīng)。這些算法在某些用例中運行良好。然而，它們并不能適應(yīng)我們?nèi)粘－h(huán)境中存在的噪音的多樣性和可變性。

存在兩種基本噪聲類型： 固定的 和 非靜止 ，如圖 4 所示。

圖 4 。白噪聲（平穩(wěn)）和啁啾噪聲（非平穩(wěn)）的 SpeCTR 圖

把靜止的噪音想象成一種可重復(fù)但又不同于人聲的聲音。傳統(tǒng)的 DSP 算法（自適應(yīng)濾波器）可以很有效地濾除這些噪聲。

非平穩(wěn)噪聲具有復(fù)雜的模式，很難與人的聲音區(qū)分開來。信號可能很短，來去非常快（例如鍵盤輸入或警報器）。有關(guān)技術(shù)上更正確的定義，請參閱此 Quora 文章 。

如果你想同時戰(zhàn)勝靜止和非靜止噪聲，你需要超越傳統(tǒng)的 DSP 。在 2Hz ，我們相信深度學(xué)習(xí)可以成為處理這些困難應(yīng)用的重要工具。

用深度學(xué)習(xí)分離背景噪聲

關(guān)于將深度學(xué)習(xí)應(yīng)用于噪聲抑制的一篇基礎(chǔ)論文似乎是 2015 年徐勇著 。

Yong 提出了一種回歸方法來學(xué)習(xí)為每個音頻頻率生成一個比率掩碼。所產(chǎn)生的比率掩?？梢允谷说穆曇舯３滞暾h除外來噪音。雖然遠不是完美的，但這是一個很好的早期方法。

在隨后的幾年里，許多不同的方法被采用；高級方法幾乎總是相同的，包括三個步驟，如圖 5 所示：

數(shù)據(jù)收集 ：將干凈語音與噪聲混合生成大數(shù)據(jù)集

培訓(xùn) ：在輸入時將此數(shù)據(jù)集饋送給 DNN ，在輸出時向 DNN 提供干凈的語音

推論 ：生成一個掩模（二進制、比率或復(fù)合），它將離開人聲并過濾掉噪聲

圖 5 。數(shù)據(jù)收集和培訓(xùn)管道

在 2Hz 頻率下，我們用不同的 DNN 進行了實驗，并提出了我們獨特的 DNN 架構(gòu)，可以對各種噪聲產(chǎn)生顯著的效果。在嘈雜的演講中，平均 MOS 評分 （平均意見得分）提高了 1 。 4 分，這是我們看到的最好的結(jié)果。這一結(jié)果令人印象深刻，因為在單個麥克風(fēng)上運行的傳統(tǒng) DSP 算法通常 減少 的 MOS 分數(shù)。

語音延遲。實時 DNN 可能嗎？

低延遲是語音通信的關(guān)鍵。人類在交談時可以忍受長達 200 毫秒的端到端延遲，否則我們會在通話中互相交談。潛伏期越長，我們就越注意到它，也就越惱火。

有三個因素會影響端到端延遲：網(wǎng)絡(luò)、計算和編解碼器。通常網(wǎng)絡(luò)延遲的影響最大。編解碼器的延遲在 5-80ms 之間，這取決于編解碼器及其模式，但現(xiàn)代編解碼器已經(jīng)變得相當高效。計算延遲實際上取決于很多因素。

計算延遲使 dnn 具有挑戰(zhàn)性。如果你想用 DNN 來處理每一幀，你就有可能引入大的計算延遲，這在現(xiàn)實的部署中是不可接受的。

根據(jù)不同的延遲因素計算：

計算平臺能力

在耳機里運行一個大的 DNN 不是你想做的事情。有 CPU 和功率限制。實現(xiàn)實時處理速度是非常具有挑戰(zhàn)性的，除非平臺有一個加速器，它可以使矩陣乘法更快、更低的功耗。

DNN 體系結(jié)構(gòu)

DNN 的速度取決于你有多少個超參數(shù)和 DNN 層，以及你的節(jié)點運行什么操作。如果你想用最小的噪聲產(chǎn)生高質(zhì)量的音頻，你的 DNN 不能很小。

例如， Mozilla rnnoise 非?？欤?也或許可以放入耳機中。然而，它的質(zhì)量并不令人印象深刻的非平穩(wěn)噪聲。

音頻采樣率

DNN 的性能取決于音頻采樣率。采樣率越高，需要提供給 DNN 的超參數(shù)就越多。

相比之下， Mozilla rnnoise 使用分組頻率的頻帶，因此性能對采樣率的依賴最小。雖然這是一個有趣的想法，但這對最終質(zhì)量有不利影響。

窄帶 音頻信號（ 8kHz 采樣率）質(zhì)量較低，但我們的大多數(shù)通信仍在窄帶中進行。這是因為大多數(shù)移動運營商的網(wǎng)絡(luò)基礎(chǔ)設(shè)施仍然使用窄帶編解碼器對音頻進行編碼和解碼。

由于窄帶每個頻率需要較少的數(shù)據(jù)，因此它可以成為實時 DNN 的一個良好的起始目標。但是當你需要增加對寬帶或超寬帶（ 16kHz 或 22kHz ）和全頻段（ 44 。 1 或 48kHz ）的支持時，事情變得非常困難。如今，許多基于 VoIP 的應(yīng)用都在使用寬帶，有時甚至使用全頻段編解碼器（開源的 Opus 編解碼器支持所有模式）。

在一個天真的設(shè)計中，你的 DNNMIG ht 要求它增長 64 倍，因此要支持全頻段，就要慢 64 倍。

如何測試噪聲抑制算法？

測試語音增強的質(zhì)量很有挑戰(zhàn)性，因為你不能相信人的耳朵。由于年齡、訓(xùn)練或其他因素，不同的人有不同的聽力能力。不幸的是，沒有開放的和一致的噪聲抑制基準，所以比較結(jié)果是有問題的。

大多數(shù)學(xué)術(shù)論文使用 漁業(yè) 、 莫斯 和 表 來比較結(jié)果。你向算法提供原始語音音頻和失真音頻，它會生成一個簡單的度量分數(shù)。例如， PESQ 分數(shù)在 -0 。 5-4 。 5 之間，其中 4 。 5 是一個非常干凈的演講。不過， PESQ 、 MOS 和 STOI 還沒有被設(shè)計成額定噪聲級，所以你不能盲目相信它們。在你的過程中你也必須進行主觀測試。

ETSI 室。

一種更專業(yè)的方法來進行主觀音頻測試并使其具有可重復(fù)性，就是滿足不同標準機構(gòu)制定的此類測試標準。

3GPP 電信組織定義了 ETSI 室的概念。如果您打算將您的算法部署到現(xiàn)實世界中，您必須在您的設(shè)施中有這樣的設(shè)置。 ETSI 室是構(gòu)建可重復(fù)和可靠測試的良好機制；圖 6 顯示了一個示例。

這個房間隔音效果很好。它通常還包括一個人造的人體軀干，一個在軀干內(nèi)模擬聲音的人造嘴（一個揚聲器），以及一個預(yù)先設(shè)定好的距離的具有麥克風(fēng)功能的目標設(shè)備。

這使測試人員能夠使用周圍的揚聲器模擬不同的噪音，播放“軀干揚聲器”的聲音，并在目標設(shè)備上捕獲結(jié)果音頻并應(yīng)用您的算法。所有這些都可以編寫腳本來自動化測試。

出站噪聲與入站噪聲

噪音抑制真的有很多 陰影 。

假設(shè)您正在與您的團隊參加電話會議。包括你在內(nèi)，有四個參與者在通話中?，F(xiàn)在混音中可能有四種潛在的噪音。每個人都把背景噪音傳給別人。

傳統(tǒng)上，噪聲抑制是在邊緣設(shè)備上進行的，這意味著噪聲抑制與麥克風(fēng)有關(guān)。你從麥克風(fēng)那里得到信號，抑制噪音，然后把信號傳送到上游。

由于單個 mic DNN 方法只需要一個源流，所以您可以將它放在任何地方。現(xiàn)在，假設(shè)您希望抑制所有參與者發(fā)出的麥克風(fēng)信號（ 出站噪聲 ）和揚聲器信號（ 進站噪聲 ）。

我們構(gòu)建了我們的應(yīng)用程序 克里斯普。 ，明確地處理入站和出站噪聲。

下面的視頻演示如何使用 DNN 完全消除非平穩(wěn)噪聲。

對于入站噪聲抑制，問題變得更加復(fù)雜。

你需要處理聲音和聲音的變化，這不是噪聲抑制算法的典型特征。例如，您的團隊 MIG 可能正在使用會議設(shè)備，并且坐在遠離該設(shè)備的地方。這意味著到達設(shè)備 MIG 的語音能量更低?；蛘咚麄冊谲嚿嫌?iPhone 在儀表板上給你打電話，這是一個固有的高噪音環(huán)境，由于與揚聲器的距離較遠，聲音很低。在另一種情況下，多人同時講話，你希望保留所有的聲音，而不是將其中的一些聲音作為噪音加以抑制。

當您撥打 Skype 電話時，您會聽到揚聲器中的來電鈴聲。那響聲是不是噪音？或者說“保留音樂”是不是一種噪音？我把它留給你。

向云端移動

到目前為止，您應(yīng)該已經(jīng)對噪聲抑制的最新技術(shù)有了一個堅實的概念，以及為此目的而使用的實時深度學(xué)習(xí)算法所面臨的挑戰(zhàn)。您還了解了關(guān)鍵的延遲要求，這些要求使問題更具挑戰(zhàn)性。你的噪聲抑制算法所增加的總延遲不能超過 20 毫秒，這確實是一個上限。

由于該算法完全基于軟件，它是否可以遷移到云端，如圖 8 所示？

答案是肯定的。首先，基于云的噪聲抑制適用于所有設(shè)備。其次，它可以在兩條線路（或電話會議中的多條線路）上執(zhí)行。我們認為噪音抑制和其他語音增強技術(shù)可以轉(zhuǎn)移到云端。這在過去是不可能的，因為多麥克風(fēng)的要求。移動運營商已經(jīng)制定了各種質(zhì)量標準，設(shè)備原始設(shè)備制造商必須執(zhí)行這些標準才能提供正確的質(zhì)量水平，迄今為止的解決方案是多個麥克風(fēng)。然而，深度學(xué)習(xí)使得在支持單麥克風(fēng)硬件的同時，能夠在云端抑制噪聲。

最大的挑戰(zhàn)是算法的可擴展性。

使用 NVIDIA GPUs 縮放 20 倍

如果我們希望這些算法能夠擴展到足以服務(wù)于真實的 VoIP 負載，我們需要了解它們的性能。

大型 VoIP 基礎(chǔ)設(shè)施可同時服務(wù)于 10K-100K 流。我們認識的一家 VoIP 服務(wù)提供商在一臺裸機媒體服務(wù)器上提供 3000 個 G.711 呼叫流，這是相當令人印象深刻的。

有許多因素影響媒體服務(wù)器（如 FreeSWITCH ）可以同時提供多少音頻流。一個明顯的因素是服務(wù)器平臺。與裸機優(yōu)化部署相比，云部署的媒體服務(wù)器提供的性能要低得多，如圖 9 所示。

圖 9 。云托管媒體服務(wù)器與裸機媒體服務(wù)器的平均流并發(fā)性

服務(wù)器端噪聲抑制必須是經(jīng)濟高效的，否則沒有客戶想要部署它。

我們在 2Hz 下的第一個實驗是從 CPU s 開始的。一個 CPU 核心可以處理多達 10 個并行流。這不是一個非常劃算的解決方案。

然后我們在 GPUs 上進行了實驗，結(jié)果令人吃驚。單個 NVIDIA 1080ti 可以在沒有任何優(yōu)化的情況下擴展到 1000 個流（圖 10 ）。在正確的優(yōu)化之后，我們看到了擴展到 3000 個流；更多的可能是可能的。

圖 10 。 DNN 算法在 NVIDIA 1080ti 上具有很好的可伸縮性

原始媒體服務(wù)器加載，包括處理流和編解碼器解碼仍然發(fā)生在 CPU 上。使用 GPUs 的另一個好處是，只需將一個外部 GPU 連接到您的媒體服務(wù)器盒，并將噪聲抑制處理完全卸載到它身上，而不會影響標準音頻處理管道。

用 CUDA 配料

讓我們來看看為什么 GPU 比 CPU 更好地擴展這類應(yīng)用程序。

CPU 傳統(tǒng)上，供應(yīng)商在優(yōu)化和加速單線程體系結(jié)構(gòu)方面花費了更多的時間和精力。他們實現(xiàn)了算法、過程和技術(shù)，盡可能地從單個線程中壓縮速度。由于過去大多數(shù)應(yīng)用程序只需要一個線程， CPU 制造商有充分的理由開發(fā)架構(gòu)來最大化單線程應(yīng)用程序。

另一方面， GPU 供應(yīng)商針對需要并行性的操作進行了優(yōu)化。這源于三維圖形處理的大規(guī)模并行需求。 GPUs 的設(shè)計使其成千上萬的小內(nèi)核在高度并行的應(yīng)用程序中工作良好，包括矩陣乘法。

批處理是允許并行化 GPU 的概念。您將成批的數(shù)據(jù)和操作發(fā)送到 GPU ，它并行地處理它們并發(fā)送回。這是處理并發(fā)音頻流的完美工具，如圖 11 所示。

圖 11 。這個簡化的圖表顯示了如何使用批處理在 GPU 上同時處理多個音頻幀

我們使用了 NVIDIA 的 CUDA 庫 直接在 NVIDIA GPUs 上運行應(yīng)用程序并執(zhí)行批處理。下面的代碼片段使用 CUDA 執(zhí)行矩陣乘法。

void kernelVectorMul(RealPtr dst, ConstRealPtr src1, ConstRealPtr src2, const size_t n) { const size_t i = threadIdx.x + blockIdx.x * blockDim.x; if (i < n) dst[i] = src1[i] * src2[i]; } void Utils::vectorMul(RealPtr dst, ConstRealPtr src1, ConstRealPtr src2, const size_t n) { dim3 gridSize(n / getDeviceMaxThreadsX() + 1, 1, 1); dim3 blockSize(getDeviceMaxThreadsX(), 1, 1); kernelVectorMul <<< gridSize, blockSize >>> (dst, src1, src2, n); } void Utils::vectorMul(Vector& dst, const Vector& src1, const Vector& src2) { vectorMul(dst.getData(), src1.getData(), src2.getData(), dst.getSize()); } void Utils::matrixMulRowByRow(Matrix& dst, const Matrix& src1, const Matrix& src2) { vectorMul(dst.getData(), src1.getData(), src2.getData(), dst.getSize()); } 

下面的代碼使用 CUDA 執(zhí)行 快速傅里葉變換 。

FFT::StatusType FFT::computeBackwardBatched(ComplexTypePtr src, RealTypePtr dst) { StatusType s = cufftExecC2R(backward_handle_, reinterpret_cast(src), dst); dim3 gridSize((getBatchSize() * getForwardDataSize()) / thr_max_ + 1, 1, 1); dim3 blockSize(thr_max_, 1, 1); float val = getForwardDataSize(); kernelDivide <<< gridSize, blockSize >>> (dst, val, getBatchSize() * getForwardDataSize()); return s; } FFT::StatusType FFT::computeBackwardBatched(ComplexVector& src, Vector& dst) { return computeBackwardBatched(src.getData(), dst.getData()); } 

下載用于 Mac 的 Krisp

如果你想在你的 Mac 上嘗試基于深度學(xué)習(xí)的噪音抑制——你可以用 Crisp 應(yīng)用程序 來做。

下一步是什么？

音頻是一個令人興奮的領(lǐng)域，而噪聲抑制只是我們在太空中看到的問題之一。深度學(xué)習(xí)將帶來新的音頻體驗，在 2Hz 頻率下，我們堅信深度學(xué)習(xí)將改善我們的日常音頻體驗。在 修復(fù)語音中斷 和 高清語音播放 的博客文章中可以找到這樣的體驗。

關(guān)于作者

Davit Baghdasaryan 是 2Hz.ai 的首席執(zhí)行官兼聯(lián)合創(chuàng)始人赫茲人工智能這是一家人工智能初創(chuàng)公司，在與伯克利和埃里溫的辦公室進行實時通信時改善語音音頻質(zhì)量。

審核編輯：郭婷