Since a couple days after the release of 2.2.10, our users have reported a ton of audio issues.
This has been happening to multiple users using different devices. Nothing was changed on our side. We have since upgraded to version 2.2.12 however we are still getting reports of issues.
It seems like the majority of issues is that all of a sudden the audio is cut out for some of the remote participants. It does not seem to happen to everyone or to all other users, but a select few.
Was anything changed to cause audio being cut for users?
+1 this started happening to us too, but before we migrated to 2.2.10, I believe it’s related to chrome 140. We had this happening with more and more users, But we had a QA who was still on 139 and the meeting had no issues to him.
@vic.yang any info on what would cause this? We have not changed the code on our end however, with the number of complaints we are getting seems like something has changed.
Set audio_webrtc_mode to 0 in the JWT. This switches to the WebAssembly audio solution. The audio quality may be slightly lower, but it ensures that the “audio not heard” issue does not occur.
As for the communication with the Google team, we have already provided them with a reproducible example, and they are currently reviewing whether this is a regression bug in Chrome.
@vic.yang the problem persisted even with audio_webrtc_mode set to 0, we set a hotfix to address it but in the first meeting to validate it still occured.
@vic.yang Thank you for the reply. When the issue started we had the audio_webrtc_mode unset in our JWT. Does it default to 1? I have since set it to 0. It does not look like it is fixing the issues.
Is there anything else that could be causing these problems? We have seen some people using Safari running into the same problems.
Is it worth trying to set audio_webrtc_mode to 1 for us? With how prevalent the issues are, it is preferable that some people on chrome have audio issues instead of everyone.
I have a video calling implementation built in Vue.js, and I’m having the same problem. I can confirm that the issue is only present for users with Google Chrome version 140, and also in a newer version of Safari.
I’ve tried several methods, including the one the dev vic suggested, which is setting audio_webrtc_mode to 0 in the JWT, but unfortunately it doesn’t work. I also included patchJsMedia: true in my options to get the latest media fixes and updating my video SDK version, but that doesn’t work either.
Is there any other possible temporary solution? I’m currently working on a workaround using the UI Toolkit (I dont kwnow if it has the same problem yet) for situations like this when Zoom doesn’t work properly, although it’s not the most optimal.
Set audio_webrtc_mode to 0 in the JWT. This switches to the WebAssembly audio solution. The > audio quality may be slightly lower, but it ensures that the “audio not heard” issue does not occur.
This is currently the fastest workaround: switching to the WASM audio solution avoids the Chrome 140 regression. However, there is a limitation — since WASM audio has significant quality issues on mobile, WebRTC audio will still be used on mobile even if you set audio_webrtc_mode:0. At the moment, the impacted platform is Android Chrome 140.
In parallel, we are actively testing a server-side fix so that this issue can be resolved without requiring a JWT configuration. We plan to roll this out by the end of this week.
Here’s the link to the official Chrome regression issue for tracking progress:
Good news: The Google team has disabled the feature that caused this regression through a remote server-side configuration. As a result, audio now works correctly on Chrome 140 after restarting the browser, without requiring a new Chrome download.
However, the issue still persists on Windows Edge 140. To mitigate this, we have temporarily switched the desktop audio solution to WASM audio on the server side.
@vic.yang Thank you for the update. Can you verify that all other chromium browsers except Windows Edge 140 is working with a restart? This includes Brave and Opera.
Unfortunately, however, this is still happening. Totally randomly some people stop hearing another person. Or one person stops hearing another one person. Session ID: BvrjYJ0SS9y7rOCQ9h5q+A==
After analyzing the logs, we found that the users who couldn’t hear sound were using the problematic Chrome 140. Chrome’s remote fix requires restarting the browser to take effect.
We are also gradually deploying a server-side fix, but it will take some time. Once completed, the issue can be resolved without needing to restart the browser.