作者：Philipp Hancke（原文链接）
翻译：刘通
原标题：Goodbye macOS WebRTC audio bug
如果你在macOS系统上的Chrome中使用WebRTC，你可能曾经遇到过麦克风不工作或者你必须重启浏览器的状况。这些问题终于得到了解决，所以让我们来看看发生了什么，以及为什么花了这么就才解决这些问题。
这些bug已经存在很长时间了，最初是在2012年年中报告的。这种情况在2014年的一个更详细的WebRTC bug文件中的第二个评论中得到了更准确的评估：
一台使用Mac电脑如果正在使用Chrome而且进入到了休眠状态，之后再唤醒，这个bug更容易出现。
事实证明，这是由于CoreAudio在笔记本电脑从休眠状态恢复时发生竞争的结果。跟踪下来需要很长时间。看看在这个评论中对coreaudio和Chrome的说明—作为一个开发者，如果你能够很轻松的重现这个问题，那么你就不需要这么做了。
Google在旧金山举行的KrankyGeek活动中表示，macOS上8.5%的会话受到了这个bug的影响。在我看来，错误率不到2%（这仍然是不可接受的），但是我只是观察appear.in而得到的结果，其会给用户提供很多关于这个bug的反馈，以及如何通过重启浏览器来解决这个问题。从支持数量方面来看，已经很大程度上降低了这个bug的影响度。
WebRTC推特账号字11月14日宣布，在Chrome 62.0.3202.94中加入了一个试探性的修复。当我看到我在前面的文章中描述的那些收集的数据时我就知道，这个错误（y轴）仍然存在于这个版本中：
事实是发布了补丁但是还没有激活，其是由实验/功能flag来控制的。而这个flag好像在11月28日已经被激活，因为数据显示出这个错误的数量发生了显著下降。数据显示出效果还是很明显的。
回顾这一年的数据也是很有趣的。下图显示了不同主要Chrome版本中，以周围单位发生的错误量。令人惊讶的是，每个版本出现后错误量都有下降。这也许可以由appear.in前端弹出的一个有用的通知解释，它会让用户采取行动，比如重启浏览器来解决出现的问题。
在图的右侧，激活补丁的效果比之前的图更加明显。Chrome 63版中仍然存在这个错误，但是非常少见。与Chrome 54版中的峰值数量相比，仅由1%，所以在图表中几乎看不到。
我们当然会继续关注这个情况，但是这个解决方案看起来很有效。
