在線語音通話已經(jīng)成為人們?nèi)粘Ｉ畹囊徊糠郑珨?shù)據(jù)包常以錯誤的順序或錯誤的時間到達另一端，有時個別數(shù)據(jù)包甚至可能會完全丟失。這不僅導(dǎo)致通話質(zhì)量降低，而且是音頻和視頻傳輸都普遍存在的問題。
Google Duo （移動設(shè)備視頻通話服務(wù)）發(fā)現(xiàn)，其99％的呼叫需要處理數(shù)據(jù)包丟失、抖動過多或網(wǎng)絡(luò)延遲等問題。在這些通話中，有20％因為網(wǎng)絡(luò)問題損失了3％以上的音頻持續(xù)時間，而10％的通話則損失了至少8％的音頻。
導(dǎo)致數(shù)據(jù)包丟失的網(wǎng)絡(luò)問題的簡化圖，接收方需要對其進行抵消，以實現(xiàn)可靠的實時通信。
為了確保可靠的實時通信，有必要處理丟失的數(shù)據(jù)包，這個過程被稱為PLC。接收方的PLC負責創(chuàng)建音頻（或視頻），以填補由丟包、過度抖動或臨時網(wǎng)絡(luò)故障造成的空白（所有這三種情況都會導(dǎo)致數(shù)據(jù)丟失）。
為了解決這些音頻問題，Google Duo開始使用全新的PLC系統(tǒng)WaveNetEQ。
WaveNetEQ是基于DeepMind的WaveRNN技術(shù)生成的模型，使用大量語音數(shù)據(jù)集進行訓(xùn)練，以更為逼真地延續(xù)短語音段，從而使其能夠完全合成丟失語音的原始波形。
由于Duo采用端到端的加密，因此所有的加工處理都需要在移動設(shè)備上完成。Google稱WaveNetEQ模型速度足夠快，可以在電話上運行，同時仍提供最先進的音頻質(zhì)量和比其他當前正在使用的系統(tǒng)更自然的探測PLC。
A New PLC System for Duo
像許多其他基于Web的通信系統(tǒng)一樣，Duo也基于WebRTC開源項目。為了抵消數(shù)據(jù)包丟失的影響，WebRTC的NetEQ組件使用信號處理方法分析語音并產(chǎn)生平滑的連續(xù)性。
這對于較小的數(shù)據(jù)包丟失（20ms或更短）非常有效，但當丟失的數(shù)據(jù)包數(shù)量過多導(dǎo)致出現(xiàn)60ms或更長的時間間隔時，帶來的效果并不盡如人意。在后一種情況下，語音會變得機械化且不斷重復(fù)，這對于許多使用線上語音通話的用戶來說都是很常見的。
為了更好地解決數(shù)據(jù)包丟失的問題，Google Duo用WaveRNN的修改版本替換了NetEQ PLC組件。WaveRNN是用于語音合成的遞歸神經(jīng)網(wǎng)絡(luò)模型，它由兩部分組成：自回歸網(wǎng)絡(luò)和調(diào)節(jié)網(wǎng)絡(luò)。
自回歸網(wǎng)絡(luò)負責信號的連續(xù)性，它通過使每個生成的樣本取決于網(wǎng)絡(luò)的先前輸出來提供語音的短期和中期結(jié)構(gòu)。調(diào)節(jié)網(wǎng)絡(luò)會影響自回歸網(wǎng)絡(luò)，并產(chǎn)生與移動速度較慢的輸入功能一致的音頻。
但是，WaveRNN與其前身WaveNet一樣，是在考慮了文本到語音（TTS）應(yīng)用程序的情況下創(chuàng)建的。作為TTS模型，WaveRNN會提供有關(guān)其應(yīng)說和如何說的信息。
調(diào)節(jié)網(wǎng)絡(luò)直接接收該信息作為構(gòu)成詞語和附加韻律特征的音素形式的輸入（即所有諸如音調(diào)或音高之類的非文本信息）。從某種程度上來說，調(diào)節(jié)網(wǎng)絡(luò)能夠“窺見未來”，后續(xù)將自回歸網(wǎng)絡(luò)轉(zhuǎn)向正確的波形并進行匹配，而這些在PLC系統(tǒng)和實時通信中則無法被提供。
對于功能正常的PLC系統(tǒng)，需要從當前語音（即過去）中提取上下文信息，同時生成逼真的聲音。
Google Duo的WaveNetEQ解決方案可以在使用自回歸網(wǎng)絡(luò)保證音頻連續(xù)性的同時，使用調(diào)節(jié)網(wǎng)絡(luò)對長期特征（例如語音特性）進行建模。過去音頻信號的頻譜圖被用作調(diào)節(jié)網(wǎng)絡(luò)的輸入，該調(diào)節(jié)網(wǎng)絡(luò)提取有關(guān)韻律和文本內(nèi)容的有限信息。這些被壓縮的信息被反饋到自回歸網(wǎng)絡(luò)，該網(wǎng)絡(luò)將其與近期的音頻相結(jié)合，以預(yù)測波形域中的下一個樣本。
這與WaveNetEQ模型訓(xùn)練過程中遵循的過程略有不同，在該過程中，自回歸網(wǎng)絡(luò)接收訓(xùn)練數(shù)據(jù)中存在的實際樣本作為下一步的輸入，而不是使用生成的最后一個樣本。
這個被稱為teacher forcing的過程可確保即使在訓(xùn)練的早期階段（其預(yù)測仍為低質(zhì)量），該模型仍可學習到有價值的信息。一旦對模型進行了充分的訓(xùn)練并將其用于音頻或視頻通話后，teacher forcing只會被用于 “預(yù)熱”第一個樣本模型，然后將其自身的輸出作為下一步的輸入傳遞回去。
WaveNetEQ結(jié)構(gòu)。在推理過程中，Google通過teacher forcing用最新的音頻來“預(yù)熱”自回歸網(wǎng)絡(luò)。之后，模型將提供自己的輸出作為下一步的輸入。來自較長音頻部分的MEL頻譜圖則被用作調(diào)節(jié)網(wǎng)絡(luò)的輸入。
該模型將應(yīng)用于Duo抖動緩沖區(qū)中的音頻數(shù)據(jù)。丟包事件發(fā)生后，如果真實音頻仍然存在，Duo將無縫合并合成的、真實的音頻流。為了找到兩個信號之間的最佳對準，該模型的輸出要比實際所需要的輸出多一些，并從一個到另一個交叉淡入淡出。這樣可使過渡平滑，并避免明顯的噪音。
在60毫秒的移動范圍內(nèi)模擬音頻上的PLC事件。藍線代表實際的音頻信號，包括PLC事件的過去和將來。在每個時間步長，橙色線代表合成音頻WaveNetEQ將預(yù)測音頻是否在灰色直線處被切斷。
60 ms Packet Loss
音頻片段：音頻片段來自LibriTTS，10％的音頻被分成60 ms，然后由WebRTC默認的PLC系統(tǒng)NetEQ與Google的PLC系統(tǒng)WaveNetEQ填充。（由于微信推送最多只能上傳3個音頻文件，這里沒能列出原文中的所有音頻，包括音頻被拆分成120 ms后再填充的效果）
Ensuring Robustness
影響PLC的一個重要因素是網(wǎng)絡(luò)適應(yīng)各種輸入信號的能力，包括不同的揚聲器或背景噪聲的變化。
為了確保模型在眾多用戶中的魯棒性，Google對WaveNetEQ進行了語音數(shù)據(jù)集的訓(xùn)練，該語音數(shù)據(jù)集中包含100多位使用48種不同語言的演講者。
這使模型可以學習普適的人類語音特征，而不是某些特定的語言屬性。為了確保WaveNetEQ能夠處理嘈雜的環(huán)境，例如在火車站或自助餐廳接聽電話這樣的情形，Google通過將數(shù)據(jù)與各種背景噪聲混合來增強數(shù)據(jù)。
盡管Google的模型學習了如何逼真地延續(xù)語音，但這僅在短期內(nèi)有效——它可以完成一個音節(jié)，但不能預(yù)測單詞本身。相反，對于更長的數(shù)據(jù)包的丟失，Google會逐漸淡出直到該模型在120毫秒后保持靜音。
為了進一步確保該模型不會產(chǎn)生錯誤的音節(jié)，Google使用了Google Cloud語音轉(zhuǎn)文本API對WaveNetEQ和NetEQ的樣本進行了評估，并發(fā)現(xiàn)單詞錯誤率沒有顯著差異（即抄錄口頭語音時產(chǎn)生的錯誤文本數(shù)量）。
Google一直在Duo上試驗WaveNetEQ，結(jié)果顯示W(wǎng)aveNetEQ對通話質(zhì)量和用戶體驗都有積極的影響。WaveNetEQ已經(jīng)可以在Pixel 4手機的所有Duo通話中使用，現(xiàn)在正被推廣到其他型號及設(shè)備中。
原文鏈接：https://ai.googleblog.com/2020/04/improving-audio-quality-in-duo-with.html
