Goodbye macOS WebRTC audio bug
If you are using WebRTC in Chrome on macOS, you probably experienced a situation where your microphone would not work and you had to restart your browser. This finally got fixed so lets take a look at what happened and why it took so long.
This anecdotally happens more after a Mac that was using Chrome goes to sleep and then is resumed.
It turned out to be a race condition in CoreAudio which happened when resuming the laptop from hibernation. Tracking that down took a long time. Take a look at the instructions for sampling both coreaudio and Chrome in this comment — as a developer you don’t do that if you can easily reproduce an issue.
At the KrankyGeek event in San Francisco, Google said 8.5% of sessions on macOS were affected by that bug. In my opinion the error rate was less than 2% (which is still unacceptable), but I am only looking at appear.in which gives users a lot of feedback about that bug and how to fix it by restarting the browser. In terms of support volume that had already reduced the impact very much.
On November 14th the WebRTC twitter account announced the tentative fix was rolling out in Chrome 62.0.3202.94. The errors (counted daily on the y-axis) were still present in that version when I looked at my numbers which are gathered as described in an earlier post:
It turned out (thank you Niklas) that the fix was rolling out but not active yet which was controlled by an experiment/feature flag. This flag seems to have been toggled on November 28 which shows a significant drop in the number of errors. Having metrics which show the effect at that level of detail is quite useful obviously.
Looking back at a year worth of data is also interesting. The following graph shows the weekly occurences of the bug in different major Chrome versions. The overall number of errors is decreasing slightly with each release which is surprising given that appear.in has grown significantly. This can probably be explained by the appear.in frontend showing a helpful notification which allows the users to take action such as restarting the browsers.
At the right side of the graph the effect of activating the fix is even more visible than in the previous graph. The bug still happens in Chrome 63 but is very rare. Compared to the peak numbers in Chrome 54 its merely 1%, making it barely visible in the graph.
We will of course continue to monitor the situation but the fix looks quite promising.