Does the WebSDK have AEC (Acoustic Echo Cancellation) built in, or utilize Chrome’s WebRTC AEC?
It looks like Zoom doesn’t use WebRTC fully so I’m thinking the answer to the latter is no, but is there any form of AEC?
We are have a lot of issues with echos that aren’t there with the native client I believe, which is why I’m asking this question.
Hey @stan_b,
It should have echo cancellation built in. @michael_p.zoom or @JackYang, can you confirm?
Thanks,
Tommy
Thanks, there seems to be a pretty big difference in audio quality vs the native client and we’d like to understand more what the differences could be.
Hi @stan_b
Yes the WebSDK has Acoustic Echo Cancellation built in. However the performance isn’t as good as using the native client. We are working on improving this feature and hope to release this in the near future.
@michael_p.zoom we did some testing just yesterday with the Web Client and the Web SDK and are seeing a massive difference in AEC performance. This is with two web based solutions that seem nearly identical on the surface.
In many tests with the same hardware and volume settings, the best performance by far was with the native client as you mentioned. However the Web Client often was very good.
The Web SDK (latest version with matching AV libs) however was nearly unusable with. In our testing a particular device (Surfacebook) echoing back very badly and we couldn’t stop it.
Again it’s odd that launching a Web Client fixes the issue, but Web SDK is unusable.
Both seem to have IndexedDB entries for AEC delay, but I’m doubting it’s actually on for Web SDK right now due to a bug. The base AV libs we are loading also refer to AEC.
Can you please look into this? We are finding just once device is hampering the ability for a meeting to continue due to the poor/disabled AEC. This is impacting our customers’ usage of our product. I’m hoping this is as simple as a misconfiguration or small bug!
Hi @stan_b,
Sure, thanks for providing details, we’ll file this as a bug and have the backend Engineering team look at this. Can you provide the meeting IDs that you used as well?
Thanks
@michael_p.zoom it happens with every meeting from multiple accounts, for example we can create a meeting and join the same one with native, web client and web sdk and it only occurs on web sdk.
@michael_p.zoom here’s a recent meeting ID we just replicated it in again: ***********
This time we had a different laptop on the other end and via the Web SDK echo was so bad it was unusable. We then switched to using Web Client for the same exact meeting (we never ended it, just the offending laptop re-joined) and the problem went away.
*This post has been edited to remove any meeting / webinar IDs
Hi @stan_b,
Thanks for providing the meeting ID. This might be an issue with our AV library. I’ll report this to our Engineers and follow back if we need anymore details so that we can improve echo issue.
Thanks
@michael_p.zoom we have an interesting data point in that we used the WebSDK + the Web Client AV libs (by changing the CDN path to the private one used by Web Client), and it was no better.
It seems to be an issue with something around the management of the AEC. It’s a massive difference between the two.
We’ve primarily been able to replicate this using lower-end laptops and hardware that is bad at AEC themselves. This includes some HP laptops and a Microsoft Surface (not Surfacebook).
Thanks @tommy. Was able to reproduce today the same ineffective AEC on 1.7.6.
It seems to be worse when switching tabs, something we don’t see with the Web Client at all.
Hey @stan_b,
Thanks for additional details! We will provide updates on progress of the issue.
-Tommy
@tommy any update? this has been really easy for us to reproduce side-by-side with the Web Client.
This issue is causing very large issues on our end due to our users situations, and I’m sure is also prevalent for all customers manifesting as far reduced sound quality.
Hi @stan_b,
Right now our Web SDK team is working on security related to changes mandated by our 90 day Security feature freeze. You can subscribe to our Web SDK Change log page to receive updates on any new features or enhancements.
Thanks
@michael_p.zoom I completely understand the feature freeze, but this isn’t a new feature. It’s a critical part of the Web SDK for use with computer audio. Without it, quality degrades rapidly and one of the core features of Zoom (audio communication) becomes ineffective.
It’s an insidious one, too, because it often just gets chalked up as hardware issues or such. However it is driving people away from the platform – we have users that cannot meet on Zoom now and are giving up. In fact we had to force computer audio off and that caused another level of issues on top of that.
Hey @stan_b,
We understand the difficulties here, we are working to fix it, but currently don’t have an exact timeline.
As a work around, can you use the Zoom Mobile / Desktop App?
Thanks,
Tommy
@tommy thanks for the response, is this at least something confirmed from your end?
Sadly we can’t use the mobile or desktop app right now, nor the Web Client because of some of our customizations. The Web Client works – it’s just the Web SDK that seems to exhibit the issue.
For that reason it seems so close… they seem to nearly share the same codebase.
Hey @stan_b,
Not confirmed yet, but we are investigating. We have not seen reports of anyone else with this issue.
In the meantime you could use the Web Client.
Thanks,
Tommy
@tommy sadly we cannot use the Web Client due to our customizations.
This is pretty tricky to trace down, not surprising others have not reported as they probably just chalk it up to hardware/user issues.
However, as mentioned we have done blind tests, A/B comparisons, etc and it’s extremely evident that the Web SDK behaves drastically different in AEC than the Web Client.
Because of our sensitivity to this, we were hit very hard. Thanks for the update. We are looking forward to an update.