BETAIf you have been connecting to WebEx meetings on Linux using Chrome/Chromium versions 79 or 80, you might have run into issues where your microphone randomly stops working and other participants cannot hear you. When trying to reconnect to the meeting, the connection process might hang for a long time. In Chrome’s Task Manager you will find that the “Utility: Audio Service” thread is using 100% or 200% CPU.
While WebEx triggers the bug most frequently, it is not a bug in WebEx: it has also been reported with Bluejeans and Gotomeeting and other conferencing solutions that use WebRTC technology. It is a bug in the PulseAudio backend in Chrome 79 and Chrome 80. I spent some time tracking this down, although someone else beat me to fixing it (no complaints). Here is the bug report and the fix.
The good news is that it’s fixed in Chrome 81.0.4044.62 and later, so the solution is to upgrade Chrome/Chromium. I am making this blog post as a note for anyone else who is looking for the solution to this problem.
Technical detail:
Every 1.5s WebEx refreshes the microphone/speaker/camera list by calling the JavaScript function navigator.MediaDevices.enumerateDevices(). When using PulseAudio, Chromium’s underlying implementation of that function calls, amongst other functions, AudioManagerPulse::GetInputStreamParameters() which is where the bug is. This function fails to lock the PulseAudio mainloop lock before calling into pa_context_get_source_info_by_name() in the PulseAudio library. The pa_context_get_source_info_by_name() function sends a request to the PulseAudio server and enqueues a dispatch entry so that the library knows what to do when the response arrives. Because of the lack of locking, there is a race condition: if another Chrome thread is executing in the PulseAudio library at the same time, the PulseAudio library’s dispatch queues can become corrupted.
