The audio quality issue with the web sdk is also (after many tests with different hardware profiles) related to user’s CPU capacities.
To make it simple for people here that did not perform any performance tests, the web SDK is doing everything by CPU : tasks like audio processing & so on but also video encoding.
Video encoding will use at least 1 complete CPU, and from what i have monitored during tests with multiple hardware it can use much more depending on the situation and the hardware.
But i’m pretty sure that over the net, most of “basic” users (understand non IT people with monster machines) use to buy entry level computer with let say dual core cheap CPU.
With such low specs machines, just running an integrated application with zoom web SDK (with nothing else running on same machine) would use more or less 80% of the available CPU. This is just enough to have both audio & video working with sometime some impacts if something else is running on the same machine.
If you start to activate screen sharing (or just application/tab sharing as screen would be even worse), then it will start to consume more CPU for the video processing and since there is not much this would have a direct impact on audio processing on this host machine, thus drop audio quality delivered to all meeting participants.
So don’t forget about that too when you face such issue. There is not a single source for this kind of issue. Fixing web sdk library is one thing, running on too low specifications (unfortunately that’s a requirements for web sdk) is another one.