浏览器实验中的故障排除

NewVoiceMedia 全球电信与服务经理Alfred Brooks 遇到了客户联络中心代理报告的严重降级音频的问题，本文将介绍他是如何一步步分析问题并最终确定错误是由Chrome实验中对AEC3功能测试引起的。LiveVideoStack对文章进行了摘译。

文 / Al Brooks

翻译 / 咪宝

原文 

https://webrtchacks.com/troubleshooting-unwitting-browser-experiments-al-brooks/

回声消除是WebRTC音频体验的基石。谷歌在这一领域投入了相当多的资金，最开始是2015年延迟无关的回声消除，现在还有一个名为AEC3的新型回声消除系统。与AEC3相关的调试问题是最难的领域之一。来自NewVoiceMedia的Al Brooks遇到了客户联络中心代理报告的严重音频降级的案例，经过长时间的调查后，发现这原来是由Chrome实验引起的，该实验为Chrome稳定的一部分用户启用了新的AEC3。

Al将带我们回顾一下他是如何分析问题并将其缩小到足以向Google提交WebRTC团队的错误。

问题

许多客户报告称2018年10月24日在代理出口音频流上遇到严重的降级音频。这是一种多呼叫支路方案，来自PSTN的呼叫者正在呼叫基于WebRTC的联络中心代理。我的客户的客户表示他们基本上无法理解代理人说话。

TL;DR

谷歌在Chrome 69稳定版中发布了“稳定实验版”的回声消除功能（AEC3）。很少有幸运的人能够有资格进行Google的测试。有些情况仅当符合某些标准时才会出现：Windows操作系统、Chrome浏览器、WebRTC以及以超过104毫秒的块的形式发出音频脉冲的耳机。不幸的是，对AEC3功能的这种测试最终导致了我客户群中的一些大规模问题。

背景

典型情况包括从PSTN（客户支线）通过入站号码持有者进入的呼叫。呼叫通过SIP传递到我们的平台，同时运行客户的智能小程序配置以确定呼叫路径。可以跨各种运营商合作伙伴创建多个呼叫支路并将其桥接在一起。所有这些都在我们联系代理人之前完成。如果该代理在我们的WebRTC产品上，我们将呼叫传递给Twilio，后者处理网关转换到WebRTC代理。

 

初步分类

在初始报告之后，我们进行了典型的故障排除分类过程。我们向客户索取了一些案例，并在Twilio和我们的平台上启用了RTP跟踪。

音频捕获显示来自代理的音频降级会在系统间隔中产生“直升机”或扇形噪声。但来自Twilio服务器和我的客户WebRTC内部页面的指标都很干净，没有数据包丢失、抖动或过度延迟......

我们最初遇到的最大问题是将当前事件中无关的问题过滤掉，以及无法跨多个环境和配置重现问题。我们开始寻找操作系统版本、发布更新、浏览器、硬件、驱动程序版本之间的共性......最终，我们有太多变量来真正缩小问题的范围。在这一点上，我们知道这不是典型的WebRTC本地网络拥塞，而是在更大范围内打破了某些东西。

深入分析

在对大量误报案例分类后，我退一步试图重新定义核心问题并隔离定义事件的“签名”。 常见因素是：

• Windows操作系统

• Chrome浏览器

• 耳机使用

• 代理出口的系统音频紊乱

在这里收听一个示例，显示来自测试示例中的类似直升机的声音（低音量警告，小心声音云自动播放！）。

我开始比较我们在我的平台下游收到的音频示例。它们听起来很相似，所以我开始在Audacity中进行比较，以观察音频波的视觉效果。

使用奇怪波形记录客户的示例。

上图显示了时间分离的音频峰值。顶部的时间刻度是在几秒钟内，但仍然明显缩小。我希望音频波看起来的状态与我所看到的状态之间存在差异。具体地说音频不是整个被捕获的单词中的一个流体波。但是在完全沉默中不时会出现几小段音频。我们使用此方法来验证客户提交的与正在发生的事件相关联的示例。我们寻找那种截然不同的声音然后验证音频被分解成这些较小的部分，同时仍保持干净的指标。

放大音频会显示波形中的大间隙

我放大了前面图片的音频中断，以测量RTP的丢失。对于所有使用Jabra耳机客户的报告，这一点大约为100毫秒。由于我用鼠标选择的位置导致的微小差异。Sennheiser耳机也丢失了约64ms。很有趣的是看到并开始引导我走向溢出或缓冲的道路。可能超过某个级别的最高处理级别。

我们的第一个想法是在资源方面Chrome或Windows受到限制，但是没有亲眼看到它或者能够复制，证明了这非常困难实现。

现场参观

此时，即11月12日-19天后。们能够与现场的特定客户合作并进行全面分析。我们的目标是复制。值得庆幸的是，我们使用的笔记本电脑、客户的耳机立即取得了成功。我在客户网络（Cellular Hotspot）之外进行了测试，并验证了仍然存在从等式中删除本地网络的问题。

我经历了各种可能性以尽可能地捕捉可以开始识别趋势的一切。

 

围绕音频配置和设置收集的数据点

通过捕获一些配置数据，可以挖掘基线参考。我能够使用连接到ENA0003 DSP USB的JDra BIZ和我的戴尔Latitude E7450复制问题。基线示例显示相同的音频问题：一致的约100ms丢失。

我捕获了Chrome控制台日志，chrome：// webrtc-internals，本地PCAP，下游PCAP，甚至开始使用Windows内置录音机录制，以查看音频开始降级的位置。

下面是操作系统中录音机捕获的本地录音与跨越我们平台时下游捕获的音频文件的比较。注意相同的~100ms间隙，虽然在这个具体例子中有轻微的噪音。

局部与下游捕获显示波形的差异

这些发现使我们能够进一步缩小范围。来自耳机或进入OS /录音机应用程序的音频是纯净的。由于我们无法解密SRTP，因此PCAP没有多大帮助。当我们越过WebRTC网关时，我们能够捕获降级的音频，该网关与我们此时能够获得的客户端源一样接近。此外，我们开始收集印证这些发现的诊断音频。

我使用了16kHz的耳机捕获理论，需要将PCMU编解码器缩小到8kHz。最终，这似乎没有任何进展，我也从来没有重新审视它。

好。检查一下。Chrome和WebRTC Gateway之间正在发生一些事情。如果我们无法提取中流音频，我们将不得不遵循指标。但是，基本分类WebRTC Internals中的指标显示没有数据包丢失或抖动......这意味着在传输任何网络之前音频已被破坏。所以......必须在浏览器或操作系统中做点什么才能导致这种恶化！

Misc.缩小范围测试

让我们试试火狐浏览器。

结果：无法使用与以前相同的耳机进行复制，而无需在PC上进行任何更改。

我们再次将范围进一步缩小为只有Windows机器报告和Chrome浏览器。在Firefox音频清晰之后，Chrome上的下一个电话会立即复制问题...开始接近根本原因。

WebRTC的内置约束怎么样？我们将它们纳入我们产品的WebRTC扩展的高级选项中。结果不一致。

结果：自动增益控制（AGC）、回声消、噪声抑制或高通滤波器的组合似乎没有任何确定的积极结果。

在某些时候，Windows强制更新。当我通过“关于Chrome”按钮确认我的Chrome版本时，它也更新到了较新版本的Chrome 70。值得庆幸的是（或者不值得庆幸）我仍然可以在我的测试机器上进行更改后重现该问题。

沿着兔子洞

现在我坚信Chrome内部正在发生一些导致这种情况发生的事情，我做了排除故障的事情-喝了几杯啤酒并开始大肆宣传外围设备！然后通过自己编写之后，上网查找Chrome中内置的任何内容以诊断问题。我的数据点每次复制后都会继续增长。

当我从chrome：// webrtc-internals诊断音频录制、Chrome性能监视器、WebRTC日志、Chrome任务管理器甚至Chrome跟踪添加新的捕获点时，我仍然无法看到任何指向特定根本原因的内容。我也检查了Windows中的系统日志，只搜索在约100毫秒内或重复出现的间隔内发生的事件，Performance Monitor或Internals并没有引起我的注意。但它看起来确实很好！

回归本质

我将是第一个承认这个级别的浏览器处理是在我的头脑之上。我只是在电视上扮演一个极客。我决定回去重新检查我用经验处理的事，那就是chrome：// webrtc-internals。我已经注意到在早些示例中的趋势与复制的示例在抖动的缓冲区内的对比有严重的波动。这看起来很奇怪，所以我会进一步调查。

我从事件发生之前的几天/几周/几个月中提取了一些旧的内部日志，并发现通常抖动缓冲区本质上是平滑的，并且当抖动出现时会增加。但是，我们看到受影响的呼叫存在大量差异，峰值超过200毫秒。它上上下下没有依靠任何相应的抖动以保证上升。

在chrome：// webrtc-internals中检查复制调用的抖动缓冲区

在某个完全沮丧的时刻，我在拨打电话时将USB电缆从笔记本电脑中拿出。我碰巧打开了WebRTC Internals，并注意到当设备断开连接时抖动缓冲器图表变平。回到耳机......太棒了！

我开始乱搞Windows Sounds设置。我注意到将麦克风或扬声器静音对抖动缓冲器没有影响。但是，当我禁用该设备时，类似于拔掉它，抖动缓冲器则会变平......所以它不是来自耳机的反馈或引入计算机的USB噪声。但我没有任何结论，只有无用的数据点。然后我决定扮演疯狂的科学家。

R.I.P我的USB端口

我决定采用可以重现问题的耳机，并在呼叫中开始热交换。我发现了一些有趣的结果。基本上那些我的客户特别告知我有问题的耳机在抖动缓冲器内表现出相同的波动。我和我的客户进行了盲测，以确认哪些耳机有问题，果然，我们的结果一致。 

您可以在下面看到内置笔记本电脑扬声器/麦克风有一些小的波动。但是当我们插入某些耳机时，并且在更换设备的初始峰值之后，抖动缓冲器将一直跳跃150 + ms或者平静下来后稳定到首选的20ms。现在我们可以看到浏览器中发生的事情。我们的第一个指标参考点！

我们的SDK、服务提供商和产品之外

我用GoogleFi作为我的手机提供商。当我在PC上利用环聊进行通话时，Fi将WebRTC与Opus编解码器结合使用。我和一位同事试了一下，开始效果很好。然后我决定拉我的耳机，果然当我插回时音频波动很明显时，抖动缓冲器疯狂地飙升，我们现在有一个确认的示例不涉及任何事包括我的公司。但是为什么我找不到其他人在网上遇到问题？我很高兴我的产品不会被打破......但是我们如何解决它以减轻我的客户问题呢？

在这一点上，Twilio跳过了这个新的发现（感谢Twils！），并在Google上打开了一个bug案例。我相信他们也升级了某个联系点，以解决这个紧迫的问题

仍在收集数据中，WebRTC调试模式

我不相信我们有足够的数据来解释这到底发生了什么，所以我将继续深入挖掘。在某些时候，我偶然发现了一些启动变量，这些变量允许Chrome进入专门针对WebRTC错误跟踪的详细日志记录模式。这真是一个发现！

此模式强制浏览器中WebRTC周围的每条指令或函数详细输出到调试日志文件，或者那至少是我的看法。这是个有趣的地方......

日志显示呼叫整个生命周期。以下示例来自我的酒店房间。虽然在Wi-Fi上，签名完全匹配，但我们可以忽略质量问题的基本潜力。它经历了初始设置、STUN连接、编解码器协议等。

从我的角度来看，当我们开始看到音频问题的具体参考并迫使延迟时有所改善。当有问题的耳机插入时，该延迟可能导致抖动缓冲器急剧扩展，或者抖动缓冲器扩展是此音频延迟的副产品。我正在这里学习这个...

从第334行开始：

 

[6336:12940:1113/203204.078:WARNING:media_stream_audio_processor.cc(756)] Large audio delay, capture delay: 0ms; render delay: 390ms
[6336:12940:1113/203204.078:WARNING:render_delay_buffer.cc(387)] Receiving a first reported externally buffer delay of 390 ms.
[6336:12940:1113/203204.079:WARNING:render_delay_buffer.cc(420)] Applying internal delay of 97 blocks.
[6336:12940:1113/203204.079:WARNING:render_delay_buffer.cc(310)] New max number api jitter observed at capture block 1: ; 2 blocks
[6336:12940:1113/203204.079:WARNING:render_delay_buffer.cc(310)] New max number api jitter observed at capture block 2: ; 3 blocks
[6336:12940:1113/203204.088:WARNING:media_stream_audio_processor.cc(756)] Large audio delay, capture delay: 10ms; render delay: 390ms

这个从452开始：

[6336:12940:1113/203204.468:WARNING:render_delay_buffer.cc(420)] Applying internal delay of 98 blocks.
[6336:12940:1113/203204.468:WARNING:block_processor.cc(153)] Reset due to render buffer api skew at block 98
[6336:12940:1113/203204.478:WARNING:render_delay_buffer.cc(262)] New max number api jitter observed at render block 195:  33 blocks
[6336:12940:1113/203204.478:WARNING:render_delay_buffer.cc(420)] Applying internal delay of 96 blocks.
[6336:12940:1113/203204.579:WARNING:render_delay_buffer.cc(420)] Applying internal delay of 96 blocks.
[6336:12940:1113/203204.579:WARNING:block_processor.cc(153)] Reset due to render buffer api skew at block 126

有计划的故障排除步骤

以下是从开始到结束所涉及的步骤的细分。这一切都是我亲自执行的。虽然我们有来自不同公司和部门的大量资源进行审查并独立进行测试......如果我没有亲自去做，那么列表上的内容并不清晰简洁。

看看AEC转储

我希望我能早点知道这个...这是对错误的第一个请求之一。虽然我一直在捕捉它，但我不知道如何从该转储中提取或从中获取有用的东西。在chrome：// webrtc-internals中，您可以启用此框以允许生成特定于AEC周围点的音频诊断记录。

如何在chrome：// webrtc-internals中启用诊断录音

这些垃圾提供了一个名为aec_dump的文件，这是一个包含录音的存档。

• 任何处理前的原始音频输入信号

• 处理后的音频信号传递给编码器

• 远程音频信号

为了提取这些文件，需要从WebRTC库构建unpack_aecdump（或询问您当地的WebRTC专家）。使用bug中提供的转储执行此操作会产生这两个文件：

输入语音input.wav与输出语音output.wav

虽然输入wav没有失真，但您可以听出输出文件中的严重失真。在遇到错误时已经知道这一点，这将使根本原因更容易确定。它是调试工具包中非常有用的部分，遗憾的是这不是我以前见过的。在提交音频错误时提供此转储会使工程师更容易查看错误，这也有助于缩短整体解决时间。

归档Bug

现在我个人从未在视频游戏报告系统之外提交过错误。值得庆幸的是，一旦我们了解到我们不是唯一受此问题影响的人，Google就会迅速作出反应。看到它在环聊中发生了真正的固化，这是一个很大的问题，Twilio能够帮助升级。

除了要求如上所述的AEC转储之外，还有一个关于chrome：//版本页面变化的问题。 很明显，这与新的AEC3回声消除器有关，该消除器在M69和M70中为一定比例的Chrome稳定用户激活（准备向所有用户推出）。

三种耳机类型（在消费者中很少见但在联络中心很受欢迎的昂贵型号）的行为是WebRTC人们以前从未见过的，将大块音频推向音频处理模块（APM）。这些块长150ms，大于AEC3假设的最大输入大小（104ms）。

迅速准备好修复并将其推送到Chrome Canary。在Chrome Stable中，问题发生在用户身上，无法合并修复程序，但建议使用一些有用的解决方法，例如禁用回音消除（这是因为耳机在扬声器和麦克风之间有良好的隔离）甚至是一种选择退出实验的巧妙方法。几天后停止了在Chrome 70中使用AEC3的实验。自那以后我们没有收到任何进展性报告。

响应时间以及如何解决Chrome稳定版问题的实用建议都非常受欢迎。

结尾

与每个技术问题一样，在整个事件生命周期中使用简单的基线并开发配置文件总是有帮助的。这对我的公司来说是一个特别重要的问题。虽然我希望它从未发生过，但它以一种全新的独特方式让我对WebRTC重新产生了兴趣。 

精品文章推荐

技术干货：

• VMAF：未毕之旅

• 跨国实时网络调度系统设计

• 语音编解码技术演进和应用选型

• 使用级联SFU改善媒体质量和规模

• 机器学习帮助WebRTC视频质量评价

• 精致前处理，精准码控 — 极致视觉效果

• 利用JPEG制作更快，更准确的神经网络

• Zoom的Web客户端与WebRTC有何不同？