Web SDK - Audio not working with Chrome 100+ - Status?

[nvivot (Nicolas)]

Hi,

We reported a month ago that the Zoom Web SDK is not working (the audio) on Chrome browser with a user agent version over 100 via the Support center.

Even if we reported details about the issue, video & audio recording demonstrating the issue, step by step procedure to reproduce the issue on your own demonstration application, hints about the reason why it might not work, the support still continue to “try to understand what is the problem” and ask for more information. The cherry on the cake, we even had an online meeting - requested by your support - tonight, and the zoom employee did not even show up to his own meeting.

Since your support does not help at all, trying to get more information from this forum seems to be the only remaining option.

Are you aware of this issue, do you work on it, is it something related to our setup (not using yet web isolation for example) ?

Any status on that matter would be very appreciated.
FYI, you can find more information in the ticket here

Regards.

[nvivot (Nicolas)]

After almost 2 months, still no reply from anyone on that problem ?

You just need to use a Chrome browser from the beta or dev channel, or from your stable release, activate the following flag to simulate a version over 100.

The audio is really crappy, sounds like a monster, a mouse or a robot with parasites depending on the OS used.

Version 100 of Chrome browser is coming in March.

[nvivot (Nicolas)]

Up, nobody else is affected by this ?

[giancarlo1 (Giancarlo)]

@nvivot I was curious about this so I tested it(in the past months, we’ve had a lot of issues mainly related to webinars).

The audio is really crappy, sounds like a monster, a mouse or a robot with parasites

ROFL, I’m having exactly the same issue. I guess there will be a release soon to fix this?

On top of that, we’ve received an increased amount of complaints about audio issues, people not being able to hear anything after giving permissions. This happens randomly even with Chrome’s latest version, I do not know what to think anymore…

[nvivot (Nicolas)]

Well, we are fighting with the support since two months now so that somebody at Zoom start to investigate it, without any success.

Thank you very much for taking time to test this & reporting here.

@giancarlo1
About your issue on Audio. Did you upgrade to the SDK 2.1.1 recently, has the report started right after that ?
Because on our side, we noticed that with this version of the SDK, when people start to do screen sharing with Chrome Tab (not window), and the “share audio tab” check box is checked (which is the default since a while now), then the Zoom Web SDK now mute the participant that share.

This behavior was not there on the 2.0.1 and is very confusing for people (since nothing changed except a small notice when you join a meeting about the fact that you’ll be muted if you share audio tab)

Please double check that this is not the issue your customers are facing, just in case. We had to rollback yesterday back to the 2.0.1 because of that as many of our users were complaining about it.

[MaxM]

Hey @nvivot and @giancarlo1,

My apologies for the delayed response here and on your ticket. It looks like the support agent has created an issue with our engineering team and there is consistent progress. From here, the backend engineering team will investigate the cause of the issue and update you when they have a fix.

As always, thank you for reporting this issue and for your patience as we investigate it.

Thanks,
Max

[nvivot (Nicolas)]

@MaxM
Thank you for your answer.

No offense here and no personal attack here, but from the support ticket mentioned above, could you also please advice the Zoom management that we can’t continue to have such a bad support from Zoom.

We spent two month so that finally this matter can come to the ear of some (real) technical staff at Zoom.
Two month ! Do you think our job consist in loosing our time with random 1st support people that don’t understand what we talk about and loose precious time for us ?

Do we have to compute the number of man hour we spent on this and send you the billing so that you realize the impact of such a bad support quality ? I understand your management want to quickly close tickets cause you probably receive tons, or distribute tickets randomly instead of creating dedicated support staff per client cause it’s easier to manage, especially with a big turn over, but hey, we pay what i consider a very expensive price for Zoom services (when we realize how long the services are degraded, almost considered as “down” 50% of the time due to poor quality over the last two years in the APAC region) and this should include some decent support.

Anyway, as always, thank you for finally taking over that issue, hope your team will find something, no matter if this is something to fix on our (web sdk client) side or on your.

[nvivot (Nicolas)]

Still no news about this ?

[nvivot (Nicolas)]

@MaxM Do you have any news about this ?

We are kind of worried that we still have no serious support & feedback from our ticket, except saying that this is a potential bug on Chrome.
I will skip the details but first, such conclusion was led by incorrect tests on Zoom side (we highlighted it already). We doubt that this is on Chrome since it also happens on stable releases (just switching the flags)
Second, even if it’s on Chrome, isn’t it Zoom’s job to work actively with the Chrome team to fix it in order to avoid an impact customers accessing Zoom meeting with the Web SDK with Chrome 100+?

In addition to that, i heard that the next SDK release would be early March, so more or less at same time of the release of Chrome 100. I guess this mean no fix in next SDK if this is a real issue on the SDK, right ?

Zoom’s support clearly lost our trust, so hearing directly from you here would be great.

[nvivot (Nicolas)]

@donte.zoom Could you please have a look at this and get some feedback for us?

[nvivot (Nicolas)]

We have been able to identify the potential cause of the issue (at least which part is broken) by running a Web SDK app with different settings.

Global conditions for the test cases below:

• Having at least one participant using any Chrome browser stable release (no matter the OS) with the chrome flags to enforce the Major version enabled.

Bug description:

• when all participants have the flag enforced to simulate Chrome 100, the audio for all participants are high tones. (but still understandable)
• when only 1 participant of two participant has the flag enforced, this is worse and both participants get a mickey mouse voice like. (completely non-understable)

Case 1:
application used: zoom’s web sdk demo web app
zoom sdk version: 2.2.0
web isolation activated: yes
shared array buffer origin trial: no (no need since web isolation is set)
number of participants: 2
result: bugged.

Case 2:
application used: zoom’s web sdk demo web app
zoom sdk version: 2.2.0
web isolation activated: no
shared array buffer origin trial: no
result: Not bugged (but audio quality is not good + self video is deactivated due to shared array buffer not being available)

Case 3:
application used: self application
zoom sdk version: 2.0.1
web isolation activated: no
shared array buffer origin trial: yes
result: Bugged

Case 4:
application used: self application
zoom sdk version: 2.0.1
web isolation activated: no
shared array buffer origin trial: no
result: Not bugged (but audio quality is not good + self video is deactivated due to shared array buffer not being available)

We run a few other cases, i will just skip it since it’s not necessary to understand & prove the issue.

Conclusion
This prove that:

1. This error is not related to any of our (client of Zoom SDK) implementation, but on the Zoom Web SDK itself (or the underlying technology used by the SDK)
2. This error is not dependent on the Web SDK version (at the contrary of what your support is trying to sell us in order to avoid to work on it)
3. Since using web isolation or the shared array buffer OT are Zoom’s requirement to have the best experience possible on the Zoom Web SDK, this bug will definitely appear on all Zoom Web SDK customers as soon as Chrome 100 is released & available (end of March) Since the version 100 won’t be available at same time on all platform, we are talking here about the worse case scenario, the mickey mouse non-understandable voice. People won’t therefore be able to use Zoom Web SDK anymore on Chrome 100+.
4. This issue seems to be related to the shared array buffer technology used with Zoom Web SDK.

We wasted a lot of efforts so that your support can understand that this is a big problem. We provided everything so that they can reproduce it but still they are not able to reproduce anything or to correctly understand what is the issue while just a “simple” non Zoom developer could understand it & reproduce it as well in a few minutes (@giancarlo1)

I won’t post any of the internal exchanges we got with Zoom support here, but it’s a real shame and i’ve never seen a quality like this (not sure “quality” is still the correct term to use)

There is still one thing i would like to jump into from what Zoom support reported to us on that ticket if you don’t mind, cause this is important.
You told us that even if there is bug, this is on Chrome and you can’t do anything with it. Come on, it’s your technology, not our. If there is an issue when using chrome’s technology with your SDK, it’s your responsibility to report it and work closer with Chrome so that they can fix it if it’s really on their side, or you can fix it with their feedback if it’s an integration issue on your SDK.

Last but not least, cause i think you still don’t get the whole picture here.
This bug will happen and affect 100% of users joining Zoom meeting through the Web SDK. But this will also affect any of the other users joining the same Zoom meeting, no matter if they join via phone or native zoom apps.

Not only this will impact Zoom’s branding (especially if people find out that some of your customers warned you about this 3 months before) but also companies using Zoom Web SDK, especially the one basing 100% of their business on online activities.
If you kill your clients, you also kill your own business isn’t it? So, if you understand that point, do you still think it isn’t in your interest - if not your responsibility - to work on it or at least provide a better support ?

I really hope you will open your eyes before that mess is real.

[nvivot (Nicolas)]

And again:

Since:

• the chrome flag only enforce the version to 100 on the user agent string
• your web SDK as well as your backend services are clearly doing things around this user agent string to determine which audio & video technology / buffers / etc to use for the data encoding & streaming. (based on your source code, i could not exactly say how much you rely on the version format since you only provide minified & obfuscated version of your sources)

Are still 100% confident to say that if there is a bug, it’s on Chrome and not on Zoom side ?

This flag has been provided so that developers (this includes Zoom’s developers) can test their solutions with this kind of user agent string before such version is out there.

[lfrancia (Lara Joy)]

Hi,

We are not getting any response on our ticket from your customer support team so, I have decided to follow it up here. We have already given all the information you need to replicate this issue. Could you please give us an update? Chrome v.100 release is next month already and I really hope you have enough time to address this issue.

Looking forward to your soonest reply here or on our zoom support ticket.

Thanks,
Lara

[lfrancia (Lara Joy)]

Hi,

Anyone from Zoom can reply to our inquiries regarding this issue either here on devforum or on the support ticket?

We have provided you with all the test conditions needed to replicate the issue. We used those same test conditions on multiple devices and tested them by different users and we all got the same result. We also used your latest Zoom Sample Web App with the latest Zoom Web Meeting SDK and we always get the same issue.

We are thankful that you tried to replicate it after lots of follow-ups but after informing us that you did not encounter the same issue you did not inform us what the steps you did and what were your test conditions. You also did not acknowledge our follow-up to have an online meeting to debug/test the issue together online since we think it is faster.

We are running out of options here so we hope you do your part too to resolve this issue, which will affect not just us but all the users who will be using your Web SDK on Chrome v.100.

By the way, here is the Chrome v100 release schedule.

Looking forward to your soonest reply.

Thanks,
Lara

[nvivot (Nicolas)]

Here is another series of tests / analysis to show that the Zoom Web SDK is not compatible with a 3 digits major version of browsers (Chrome in this case since it’s the first reaching 3 digits in a few days)

You’ll find the same analysis as a document on the ticket mentioned earlier in this thread. I add the details here for those who cannot access out ticket to share the details.

---

The issue

As a reminder, the issue is that if one participant joins a meeting with a major version of 3 digits on Chrome browser, voices going in and out for that participant will be helium-like voices.
If 2 or more participants join the same meeting with a 3 digit major version, the same issue happen except that the voices are high tone-like and not helium-like.

---

How to simulate a major or minor version of chrome browser with 3 digits

As you may know, the Chrome team released two features in early December to be able to test applications with a chrome version to 100 in the user-agent string.
You can activate the simulation of a Major version of 100 for your Chrome browser, or (from Chrome 98) the simulation of a Minor version of 100 for your Chrome browser, from your Chrome flags as shown below

With that in mind, here are 3 simple tests you can perform yourself to reproduce & find the condition of the issue.

---

Case 1 (base case) : Simulating a major version of 100 on one participant in a Zoom meeting, joining via Web SDK and with SAB (Shared Array Buffer) active

Context

• 3 participants join a Zoom meeting from a web application using the Zoom Web SDK (any version of the SDK is affected so this parameter does not matter)
  You can use your own application, or the official Zoom Demo web application.
• Only one of the participants joins with a simulated major version of 100 of its Chrome browser. The two other participants join with a stable release of Chrome, no matter the version.
• Participants must activate their audio (join by computer) and talk to each other.
• To have SAB active on the application you use for the tests, either setup the SAB Origin Trial, or setup the web isolation.
  
  

Results

• Any audio coming out from User 1 and at the destination of User 2 or User 3 has a helium- like voice on the User 2 and 3 sides.
• Any audio coming out from User 2 and at the destination of User 1 has a helium-like voice on the User 1 side.
• Any audio coming out from User 2 and at the destination of User 3, and vice versa is normal.

As a result, User 1 voice is helium-like for any other participant, and any other participant voice is helium-like for User 1. Other participants can hear each other with a normal voice.

---

Case 2 : Same as Case 1 but with SAB non active

Context

The context is the same as case 1, but with Shared array buffer non active (no SAB Origin Trial, no web isolation on the tested application)

Results

No audio issue, except that the quality is not perfect since SAB is not active.

---

Case 3 : Simulating a minor version of 100 on one participant in a Zoom meeting, joining via Web SDK and with SAB (Shared Array Buffer) active

Context

The context is the same as case 1, with the difference that User 1 activates the second Chrome flags to simulate a minor version of Chrome 100. Deactivate the Major version flag if it’s still active, and activate the Minor version flag.

Results

No audio issue.

Conclusion

As illustrated in case 1, the issue happens only when both the Share Array Buffer is active and the Chrome major version is 3 digits in the user agent string. for at least one of the participants.

Another point illustrated in case 1 is that only the users having these conditions are affected (but it affects how the other participants hear them). A special note here, when multiple participants join the same meeting with these conditions, instead of being helium-like, their voice (and what they hear) is high tone-like (slightly more difficult to hear the difference but easy when you are used to the voice of someone)

All of this shows that the issue is within User 1 Zoom Web SDK components, and seems to be at the SAB feature level, altering the audio out & in processing.

Since the only difference between a base Chrome browser and the one with the Major version 100 flag activated is the user-agent string sent by the browser, this indicates that something on the Zoom Web SDK is done based on the user-agent string and bugged when the major version of Chrome has 3 digits.

My guess here is that the audio processing is based on the browser type & version, and because of these 3 digits not being handled correctly, the component fails to correctly compute audio output data and interpret audio input data coming from other participants.

Again, we are not Zoom’s developers, and only Zoom’s developers can say whether this is at Zoom level (implementation / usage of SAB), or deeper on the Chrome side in the SAB feature itself. And this is why we ask you to investigate this matter more seriously, because only you can know where this user-agent string analysis is done if it’s the real cause, or if there is something else.

Hope this is crystal clear and that someone on Zoom will seriously consider to spend a bit of time on that.

[nvivot (Nicolas)]

Here is the reply from Chrome team about this issue

@MaxM @donte.zoom Is it possible to have a serious look at it ?

[donte.zoom (Donte)]

@nvivot,

Thank you for posting! I will bring this up to our SDK Team and follow up here.

More Soon,
Donte

[lfrancia (Lara Joy)]

Hi @donte.zoom ,

Thank you so much!
By the way, here is our existing zoom support ticket for this issue. Zoom Support

Thanks,
Lara

[nvivot (Nicolas)]

@donte.zoom

Thank you.

By the way, the potential issue in your source code is here, on the js_media_min.js, the getBrowserVersion function is returning the two first digits only and therefore in the case of a version 100+ would return 10…

So i would say, if you do something specific based on that extracted version, then it’s definitely bugged for any browser having a major version of 3 digits.

Note: this is one place, i did not check everything and there might be other places where this is also wrong.

Note2: this function to detect the browser version & extract the major version is correct in the main zdk script (zoom-meeting-x.x.x.min.js in the NPM packages)

So you have duplicated code doing same thing but bugged at some places… you may want to factorize a bit the SDK to simplify its maintenance & debugging.

[nvivot (Nicolas)]

Just in case you still think this problem is not on Zoom, please check this code, changing the behavior of the audio based on Chrome version over 74, which obviously is not going to work with the bugged detection function shown above…

This seems to alters the sample rate & other things related to the audio transmission and probably explain why voices are so bad when joining with a Chrome major version of 100+.

Please fix it ASAP.