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