`startAudio` takes too much time to complete on some devices

Video SDK Web
1

Video SDK Type and Version
2.1.10

Description

  • On some devices, the stream.startAudio function takes an unusually long time to complete immediately after joining a meeting.
    According to a customer report, it takes approximately 15 seconds to complete, which is far too long to be acceptable.

This is my customer session ids:

ejaMB+wYQ6qB7YpBmIIn6w==
tiNHlJpBRP2I8HOzOTleaw==

This is my code:

        await stream.startAudio({ mute: false });

I would really appreciate your support on this as soon as possible.
Thank you!

Error?
No error

Browser/client type and version

  • Win11
  • Edge version 119
1 Like
3

Hi @lmtruong1512 I submitted an engineering ticket to take a look on the backend for the meetings you provided. The reference is ZSEE-164564

Just a couple of additional question I think would help the investigation. Do you know what audio devices they tried to connect to? Or are they using default system audio? Also, browser load could play a role in delayed connection. Since they are using Edge, could you also verify if the browser is using sharedArrayBuffer?

1 Like
5

Hi @lmtruong1512

Thanks for your feedback.

ejaMB+wYQ6qB7YpBmIIn6w==
tiNHlJpBRP2I8HOzOTleaw==

We analyzed the session logs and found that it took an unusually long time—around 15 seconds—to establish a connection to the Zoom WebRTC server.

We’re currently investigating the root cause of this issue and will keep you updated.

Thanks
Vic

1 Like
6

Hi @vic.yang, thank you!
We’ve noticed that starting and rendering the video is still fast — the delay only seems to affect audio.
Does video rendering not rely on WebRTC the same way audio does?

7

According to the session logs, video rendering was still using the WASM solution, so there was no impact on the video.

Thanks
Vic

1 Like
8

Hi @vic.yang,
We tried disabling WebRTC for both video and audio by setting video_webrtc_mode and audio_webrtc_mode to 0. After doing so, the issue no longer appears — audio starts faster now.

However, I’m not sure if this temporary workaround might cause any side effects.
Please continue investigating the root cause and keep me updated on any progress.
Thank you very much!

9

@vic.yang One more question,
Is it correct that WebRTC is only supported starting from version 2.1.0? Also, from that version onward, if the video_webrtc_mode and audio_webrtc_mode options aren’t set, does it automatically detect the appropriate settings by default?

Thanks

10

Hi @lmtruong1512

Is it correct that WebRTC is only supported starting from version 2.1.0?

Not entirely correct—WebRTC audio has been supported for a long time, but WebRTC video has only been supported since version 2.1.0.

does it automatically detect the appropriate settings by default?

Yes. Video SDK will determine whether to enable WebRTC if no relevant JWT fields are specified.

As for the issue where using WebRTC audio causes startAudio to take a long time to succeed — we’ve identified the root cause. It’s likely due to the user’s network blocking ports 8803–8810, which prevents a direct connection to the WebRTC server. As a result, the SDK will fall back to connecting via a TURN server. Currently, the fallback timeout is set too long, and we plan to optimize this in a future release.

Thanks
Vic

1 Like