如何排除瀏覽器實(shí)驗(yàn)中的故障？

回聲消除是WebRTC音頻體驗(yàn)的基石。谷歌在這一領(lǐng)域投入了相當(dāng)多的資金，最開始是2015年延遲無關(guān)的回聲消除，現(xiàn)在還有一個(gè)名為AEC3的新型回聲消除系統(tǒng)。與AEC3相關(guān)的調(diào)試問題是最難的領(lǐng)域之一。來自NewVoiceMedia的Al Brooks遇到了客戶聯(lián)絡(luò)中心代理報(bào)告的嚴(yán)重音頻降級(jí)的案例，經(jīng)過長(zhǎng)時(shí)間的調(diào)查后，發(fā)現(xiàn)這原來是由Chrome實(shí)驗(yàn)引起的，該實(shí)驗(yàn)為Chrome穩(wěn)定的一部分用戶啟用了新的AEC3。

Al將帶我們回顧一下他是如何分析問題并將其縮小到足以向Google提交WebRTC團(tuán)隊(duì)的錯(cuò)誤。

問題

許多客戶報(bào)告稱2018年10月24日在代理出口音頻流上遇到嚴(yán)重的降級(jí)音頻。這是一種多呼叫支路方案，來自PSTN的呼叫者正在呼叫基于WebRTC的聯(lián)絡(luò)中心代理。我的客戶的客戶表示他們基本上無法理解代理人說話。

TL;DR

谷歌在Chrome 69穩(wěn)定版中發(fā)布了“穩(wěn)定實(shí)驗(yàn)版”的回聲消除功能（AEC3）。很少有幸運(yùn)的人能夠有資格進(jìn)行Google的測(cè)試。有些情況僅當(dāng)符合某些標(biāo)準(zhǔn)時(shí)才會(huì)出現(xiàn)：Windows操作系統(tǒng)、Chrome瀏覽器、WebRTC以及以超過104毫秒的塊的形式發(fā)出音頻脈沖的耳機(jī)。不幸的是，對(duì)AEC3功能的這種測(cè)試最終導(dǎo)致了我客戶群中的一些大規(guī)模問題。

背景

典型情況包括從PSTN（客戶支線）通過入站號(hào)碼持有者進(jìn)入的呼叫。呼叫通過SIP傳遞到我們的平臺(tái)，同時(shí)運(yùn)行客戶的智能小程序配置以確定呼叫路徑?？梢钥绺鞣N運(yùn)營(yíng)商合作伙伴創(chuàng)建多個(gè)呼叫支路并將其橋接在一起。所有這些都在我們聯(lián)系代理人之前完成。如果該代理在我們的WebRTC產(chǎn)品上，我們將呼叫傳遞給Twilio，后者處理網(wǎng)關(guān)轉(zhuǎn)換到WebRTC代理。

初步分類

在初始報(bào)告之后，我們進(jìn)行了典型的故障排除分類過程。我們向客戶索取了一些案例，并在Twilio和我們的平臺(tái)上啟用了RTP跟蹤。

音頻捕獲顯示來自代理的音頻降級(jí)會(huì)在系統(tǒng)間隔中產(chǎn)生“直升機(jī)”或扇形噪聲。但來自Twilio服務(wù)器和我的客戶WebRTC內(nèi)部頁面的指標(biāo)都很干凈，沒有數(shù)據(jù)包丟失、抖動(dòng)或過度延遲......

我們最初遇到的最大問題是將當(dāng)前事件中無關(guān)的問題過濾掉，以及無法跨多個(gè)環(huán)境和配置重現(xiàn)問題。我們開始尋找操作系統(tǒng)版本、發(fā)布更新、瀏覽器、硬件、驅(qū)動(dòng)程序版本之間的共性......最終，我們有太多變量來真正縮小問題的范圍。在這一點(diǎn)上，我們知道這不是典型的WebRTC本地網(wǎng)絡(luò)擁塞，而是在更大范圍內(nèi)打破了某些東西。

深入分析

在對(duì)大量誤報(bào)案例分類后，我退一步試圖重新定義核心問題并隔離定義事件的“簽名”。 常見因素是：

Windows操作系統(tǒng)

Chrome瀏覽器

耳機(jī)使用

代理出口的系統(tǒng)音頻紊亂

在這里收聽一個(gè)示例，顯示來自測(cè)試示例中的類似直升機(jī)的聲音（低音量警告，小心聲音云自動(dòng)播放！）。

我開始比較我們?cè)谖业钠脚_(tái)下游收到的音頻示例。它們聽起來很相似，所以我開始在Audacity中進(jìn)行比較，以觀察音頻波的視覺效果。

使用奇怪波形記錄客戶的示例。

上圖顯示了時(shí)間分離的音頻峰值。頂部的時(shí)間刻度是在幾秒鐘內(nèi)，但仍然明顯縮小。我希望音頻波看起來的狀態(tài)與我所看到的狀態(tài)之間存在差異。具體地說音頻不是整個(gè)被捕獲的單詞中的一個(gè)流體波。但是在完全沉默中不時(shí)會(huì)出現(xiàn)幾小段音頻。我們使用此方法來驗(yàn)證客戶提交的與正在發(fā)生的事件相關(guān)聯(lián)的示例。我們尋找那種截然不同的聲音然后驗(yàn)證音頻被分解成這些較小的部分，同時(shí)仍保持干凈的指標(biāo)。

放大音頻會(huì)顯示波形中的大間隙

我放大了前面圖片的音頻中斷，以測(cè)量RTP的丟失。對(duì)于所有使用Jabra耳機(jī)客戶的報(bào)告，這一點(diǎn)大約為100毫秒。由于我用鼠標(biāo)選擇的位置導(dǎo)致的微小差異。Sennheiser耳機(jī)也丟失了約64ms。很有趣的是看到并開始引導(dǎo)我走向溢出或緩沖的道路?？赡艹^某個(gè)級(jí)別的最高處理級(jí)別。

我們的第一個(gè)想法是在資源方面Chrome或Windows受到限制，但是沒有親眼看到它或者能夠復(fù)制，證明了這非常困難實(shí)現(xiàn)。

現(xiàn)場(chǎng)參觀

此時(shí)，即11月12日-19天后。們能夠與現(xiàn)場(chǎng)的特定客戶合作并進(jìn)行全面分析。我們的目標(biāo)是復(fù)制。值得慶幸的是，我們使用的筆記本電腦、客戶的耳機(jī)立即取得了成功。我在客戶網(wǎng)絡(luò)（Cellular Hotspot）之外進(jìn)行了測(cè)試，并驗(yàn)證了仍然存在從等式中刪除本地網(wǎng)絡(luò)的問題。

我經(jīng)歷了各種可能性以盡可能地捕捉可以開始識(shí)別趨勢(shì)的一切。

圍繞音頻配置和設(shè)置收集的數(shù)據(jù)點(diǎn)

通過捕獲一些配置數(shù)據(jù)，可以挖掘基線參考。我能夠使用連接到ENA0003 DSP USB的JDra BIZ和我的戴爾Latitude E7450復(fù)制問題。基線示例顯示相同的音頻問題：一致的約100ms丟失。

我捕獲了Chrome控制臺(tái)日志，chrome：// webrtc-internals，本地PCAP，下游PCAP，甚至開始使用Windows內(nèi)置錄音機(jī)錄制，以查看音頻開始降級(jí)的位置。

下面是操作系統(tǒng)中錄音機(jī)捕獲的本地錄音與跨越我們平臺(tái)時(shí)下游捕獲的音頻文件的比較。注意相同的~100ms間隙，雖然在這個(gè)具體例子中有輕微的噪音。

局部與下游捕獲顯示波形的差異

這些發(fā)現(xiàn)使我們能夠進(jìn)一步縮小范圍。來自耳機(jī)或進(jìn)入OS /錄音機(jī)應(yīng)用程序的音頻是純凈的。由于我們無法解密SRTP，因此PCAP沒有多大幫助。當(dāng)我們?cè)竭^WebRTC網(wǎng)關(guān)時(shí)，我們能夠捕獲降級(jí)的音頻，該網(wǎng)關(guān)與我們此時(shí)能夠獲得的客戶端源一樣接近。此外，我們開始收集印證這些發(fā)現(xiàn)的診斷音頻。

我使用了16kHz的耳機(jī)捕獲理論，需要將PCMU編解碼器縮小到8kHz。最終，這似乎沒有任何進(jìn)展，我也從來沒有重新審視它。

好。檢查一下。Chrome和WebRTC Gateway之間正在發(fā)生一些事情。如果我們無法提取中流音頻，我們將不得不遵循指標(biāo)。但是，基本分類WebRTC Internals中的指標(biāo)顯示沒有數(shù)據(jù)包丟失或抖動(dòng)......這意味著在傳輸任何網(wǎng)絡(luò)之前音頻已被破壞。所以......必須在瀏覽器或操作系統(tǒng)中做點(diǎn)什么才能導(dǎo)致這種惡化！

Misc.縮小范圍測(cè)試

讓我們?cè)囋嚮鸷鼮g覽器。

結(jié)果：無法使用與以前相同的耳機(jī)進(jìn)行復(fù)制，而無需在PC上進(jìn)行任何更改。

我們?cè)俅螌⒎秶M(jìn)一步縮小為只有Windows機(jī)器報(bào)告和Chrome瀏覽器。在Firefox音頻清晰之后，Chrome上的下一個(gè)電話會(huì)立即復(fù)制問題...開始接近根本原因。

WebRTC的內(nèi)置約束怎么樣？我們將它們納入我們產(chǎn)品的WebRTC擴(kuò)展的高級(jí)選項(xiàng)中。結(jié)果不一致。

結(jié)果：自動(dòng)增益控制（AGC）、回聲消、噪聲抑制或高通濾波器的組合似乎沒有任何確定的積極結(jié)果。

在某些時(shí)候，Windows強(qiáng)制更新。當(dāng)我通過“關(guān)于Chrome”按鈕確認(rèn)我的Chrome版本時(shí)，它也更新到了較新版本的Chrome 70。值得慶幸的是（或者不值得慶幸）我仍然可以在我的測(cè)試機(jī)器上進(jìn)行更改后重現(xiàn)該問題。

沿著兔子洞

現(xiàn)在我堅(jiān)信Chrome內(nèi)部正在發(fā)生一些導(dǎo)致這種情況發(fā)生的事情，我做了排除故障的事情-喝了幾杯啤酒并開始大肆宣傳外圍設(shè)備！然后通過自己編寫之后，上網(wǎng)查找Chrome中內(nèi)置的任何內(nèi)容以診斷問題。我的數(shù)據(jù)點(diǎn)每次復(fù)制后都會(huì)繼續(xù)增長(zhǎng)。

當(dāng)我從chrome：// webrtc-internals診斷音頻錄制、Chrome性能監(jiān)視器、WebRTC日志、Chrome任務(wù)管理器甚至Chrome跟蹤添加新的捕獲點(diǎn)時(shí)，我仍然無法看到任何指向特定根本原因的內(nèi)容。我也檢查了Windows中的系統(tǒng)日志，只搜索在約100毫秒內(nèi)或重復(fù)出現(xiàn)的間隔內(nèi)發(fā)生的事件，Performance Monitor或Internals并沒有引起我的注意。但它看起來確實(shí)很好！

回歸本質(zhì)

我將是第一個(gè)承認(rèn)這個(gè)級(jí)別的瀏覽器處理是在我的頭腦之上。我只是在電視上扮演一個(gè)極客。我決定回去重新檢查我用經(jīng)驗(yàn)處理的事，那就是chrome：// webrtc-internals。我已經(jīng)注意到在早些示例中的趨勢(shì)與復(fù)制的示例在抖動(dòng)的緩沖區(qū)內(nèi)的對(duì)比有嚴(yán)重的波動(dòng)。這看起來很奇怪，所以我會(huì)進(jìn)一步調(diào)查。

我從事件發(fā)生之前的幾天/幾周/幾個(gè)月中提取了一些舊的內(nèi)部日志，并發(fā)現(xiàn)通常抖動(dòng)緩沖區(qū)本質(zhì)上是平滑的，并且當(dāng)抖動(dòng)出現(xiàn)時(shí)會(huì)增加。但是，我們看到受影響的呼叫存在大量差異，峰值超過200毫秒。它上上下下沒有依靠任何相應(yīng)的抖動(dòng)以保證上升。

在chrome：// webrtc-internals中檢查復(fù)制調(diào)用的抖動(dòng)緩沖區(qū)

在某個(gè)完全沮喪的時(shí)刻，我在撥打電話時(shí)將USB電纜從筆記本電腦中拿出。我碰巧打開了WebRTC Internals，并注意到當(dāng)設(shè)備斷開連接時(shí)抖動(dòng)緩沖器圖表變平?；氐蕉鷻C(jī)......太棒了！

我開始亂搞Windows Sounds設(shè)置。我注意到將麥克風(fēng)或揚(yáng)聲器靜音對(duì)抖動(dòng)緩沖器沒有影響。但是，當(dāng)我禁用該設(shè)備時(shí)，類似于拔掉它，抖動(dòng)緩沖器則會(huì)變平......所以它不是來自耳機(jī)的反饋或引入計(jì)算機(jī)的USB噪聲。但我沒有任何結(jié)論，只有無用的數(shù)據(jù)點(diǎn)。然后我決定扮演瘋狂的科學(xué)家。

R.I.P我的USB端口

我決定采用可以重現(xiàn)問題的耳機(jī)，并在呼叫中開始熱交換。我發(fā)現(xiàn)了一些有趣的結(jié)果?；旧夏切┪业目蛻籼貏e告知我有問題的耳機(jī)在抖動(dòng)緩沖器內(nèi)表現(xiàn)出相同的波動(dòng)。我和我的客戶進(jìn)行了盲測(cè)，以確認(rèn)哪些耳機(jī)有問題，果然，我們的結(jié)果一致。

您可以在下面看到內(nèi)置筆記本電腦揚(yáng)聲器/麥克風(fēng)有一些小的波動(dòng)。但是當(dāng)我們插入某些耳機(jī)時(shí)，并且在更換設(shè)備的初始峰值之后，抖動(dòng)緩沖器將一直跳躍150 + ms或者平靜下來后穩(wěn)定到首選的20ms?，F(xiàn)在我們可以看到瀏覽器中發(fā)生的事情。我們的第一個(gè)指標(biāo)參考點(diǎn)！

我們的SDK、服務(wù)提供商和產(chǎn)品之外

我用GoogleFi作為我的手機(jī)提供商。當(dāng)我在PC上利用環(huán)聊進(jìn)行通話時(shí)，F(xiàn)i將WebRTC與Opus編解碼器結(jié)合使用。我和一位同事試了一下，開始效果很好。然后我決定拉我的耳機(jī)，果然當(dāng)我插回時(shí)音頻波動(dòng)很明顯時(shí)，抖動(dòng)緩沖器瘋狂地飆升，我們現(xiàn)在有一個(gè)確認(rèn)的示例不涉及任何事包括我的公司。但是為什么我找不到其他人在網(wǎng)上遇到問題？我很高興我的產(chǎn)品不會(huì)被打破......但是我們?nèi)绾谓鉀Q它以減輕我的客戶問題呢？

在這一點(diǎn)上，Twilio跳過了這個(gè)新的發(fā)現(xiàn)（感謝Twils?。⒃贕oogle上打開了一個(gè)bug案例。我相信他們也升級(jí)了某個(gè)聯(lián)系點(diǎn)，以解決這個(gè)緊迫的問題

仍在收集數(shù)據(jù)中，WebRTC調(diào)試模式

我不相信我們有足夠的數(shù)據(jù)來解釋這到底發(fā)生了什么，所以我將繼續(xù)深入挖掘。在某些時(shí)候，我偶然發(fā)現(xiàn)了一些啟動(dòng)變量，這些變量允許Chrome進(jìn)入專門針對(duì)WebRTC錯(cuò)誤跟蹤的詳細(xì)日志記錄模式。這真是一個(gè)發(fā)現(xiàn)！

此模式強(qiáng)制瀏覽器中WebRTC周圍的每條指令或函數(shù)詳細(xì)輸出到調(diào)試日志文件，或者那至少是我的看法。這是個(gè)有趣的地方......

日志顯示呼叫整個(gè)生命周期。以下示例來自我的酒店房間。雖然在Wi-Fi上，簽名完全匹配，但我們可以忽略質(zhì)量問題的基本潛力。它經(jīng)歷了初始設(shè)置、STUN連接、編解碼器協(xié)議等。

從我的角度來看，當(dāng)我們開始看到音頻問題的具體參考并迫使延遲時(shí)有所改善。當(dāng)有問題的耳機(jī)插入時(shí)，該延遲可能導(dǎo)致抖動(dòng)緩沖器急劇擴(kuò)展，或者抖動(dòng)緩沖器擴(kuò)展是此音頻延遲的副產(chǎn)品。我正在這里學(xué)習(xí)這個(gè)...

從第334行開始：

[6336:12940:1113/203204.078:WARNING:media_stream_audio_processor.cc(756)]Largeaudiodelay,capturedelay:0ms;renderdelay:390ms[6336:12940:1113/203204.078:WARNING:render_delay_buffer.cc(387)]Receivingafirstreportedexternallybufferdelayof390ms.[6336:12940:1113/203204.079:WARNING:render_delay_buffer.cc(420)]Applyinginternaldelayof97blocks.[6336:12940:1113/203204.079:WARNING:render_delay_buffer.cc(310)]Newmaxnumberapijitterobservedatcaptureblock1:2blocks[6336:12940:1113/203204.079:WARNING:render_delay_buffer.cc(310)]Newmaxnumberapijitterobservedatcaptureblock2:3blocks[6336:12940:1113/203204.088:WARNING:media_stream_audio_processor.cc(756)]Largeaudiodelay,capturedelay:10ms;renderdelay:390ms

這個(gè)從452開始：

[6336:12940:1113/203204.468:WARNING:render_delay_buffer.cc(420)]Applyinginternaldelayof98blocks.[6336:12940:1113/203204.468:WARNING:block_processor.cc(153)]Resetduetorenderbufferapiskewatblock98[6336:12940:1113/203204.478:WARNING:render_delay_buffer.cc(262)]Newmaxnumberapijitterobservedatrenderblock195:33blocks[6336:12940:1113/203204.478:WARNING:render_delay_buffer.cc(420)]Applyinginternaldelayof96blocks.[6336:12940:1113/203204.579:WARNING:render_delay_buffer.cc(420)]Applyinginternaldelayof96blocks.[6336:12940:1113/203204.579:WARNING:block_processor.cc(153)]Resetduetorenderbufferapiskewatblock126

有計(jì)劃的故障排除步驟

以下是從開始到結(jié)束所涉及的步驟的細(xì)分。這一切都是我親自執(zhí)行的。雖然我們有來自不同公司和部門的大量資源進(jìn)行審查并獨(dú)立進(jìn)行測(cè)試......如果我沒有親自去做，那么列表上的內(nèi)容并不清晰簡(jiǎn)潔。

看看AEC轉(zhuǎn)儲(chǔ)

我希望我能早點(diǎn)知道這個(gè)...這是對(duì)錯(cuò)誤的第一個(gè)請(qǐng)求之一。雖然我一直在捕捉它，但我不知道如何從該轉(zhuǎn)儲(chǔ)中提取或從中獲取有用的東西。在chrome：// webrtc-internals中，您可以啟用此框以允許生成特定于AEC周圍點(diǎn)的音頻診斷記錄。

如何在chrome：// webrtc-internals中啟用診斷錄音

這些垃圾提供了一個(gè)名為aec_dump的文件，這是一個(gè)包含錄音的存檔。

任何處理前的原始音頻輸入信號(hào)

處理后的音頻信號(hào)傳遞給編碼器

遠(yuǎn)程音頻信號(hào)

為了提取這些文件，需要從WebRTC庫構(gòu)建unpack_aecdump（或詢問您當(dāng)?shù)氐腤ebRTC專家）。使用bug中提供的轉(zhuǎn)儲(chǔ)執(zhí)行此操作會(huì)產(chǎn)生這兩個(gè)文件：

輸入語音input.wav與輸出語音output.wav

雖然輸入wav沒有失真，但您可以聽出輸出文件中的嚴(yán)重失真。在遇到錯(cuò)誤時(shí)已經(jīng)知道這一點(diǎn)，這將使根本原因更容易確定。它是調(diào)試工具包中非常有用的部分，遺憾的是這不是我以前見過的。在提交音頻錯(cuò)誤時(shí)提供此轉(zhuǎn)儲(chǔ)會(huì)使工程師更容易查看錯(cuò)誤，這也有助于縮短整體解決時(shí)間。

歸檔Bug

現(xiàn)在我個(gè)人從未在視頻游戲報(bào)告系統(tǒng)之外提交過錯(cuò)誤。值得慶幸的是，一旦我們了解到我們不是唯一受此問題影響的人，Google就會(huì)迅速作出反應(yīng)?？吹剿诃h(huán)聊中發(fā)生了真正的固化，這是一個(gè)很大的問題，Twilio能夠幫助升級(jí)。

除了要求如上所述的AEC轉(zhuǎn)儲(chǔ)之外，還有一個(gè)關(guān)于chrome：//版本頁面變化的問題。 很明顯，這與新的AEC3回聲消除器有關(guān)，該消除器在M69和M70中為一定比例的Chrome穩(wěn)定用戶激活（準(zhǔn)備向所有用戶推出）。

三種耳機(jī)類型（在消費(fèi)者中很少見但在聯(lián)絡(luò)中心很受歡迎的昂貴型號(hào)）的行為是WebRTC人們以前從未見過的，將大塊音頻推向音頻處理模塊（APM）。這些塊長(zhǎng)150ms，大于AEC3假設(shè)的最大輸入大小（104ms）。

迅速準(zhǔn)備好修復(fù)并將其推送到Chrome Canary。在Chrome Stable中，問題發(fā)生在用戶身上，無法合并修復(fù)程序，但建議使用一些有用的解決方法，例如禁用回音消除（這是因?yàn)槎鷻C(jī)在揚(yáng)聲器和麥克風(fēng)之間有良好的隔離）甚至是一種選擇退出實(shí)驗(yàn)的巧妙方法。幾天后停止了在Chrome 70中使用AEC3的實(shí)驗(yàn)。自那以后我們沒有收到任何進(jìn)展性報(bào)告。

響應(yīng)時(shí)間以及如何解決Chrome穩(wěn)定版問題的實(shí)用建議都非常受歡迎。

結(jié)尾

與每個(gè)技術(shù)問題一樣，在整個(gè)事件生命周期中使用簡(jiǎn)單的基線并開發(fā)配置文件總是有幫助的。這對(duì)我的公司來說是一個(gè)特別重要的問題。雖然我希望它從未發(fā)生過，但它以一種全新的獨(dú)特方式讓我對(duì)WebRTC重新產(chǎn)生了興趣。