We enable/disable camera and microphone of the local participant in a callback whenever our call state changes. Sometimes we experienced duplicated audio and/or video streams.
It turns out, while dart is single-threaded, due to its async nature, race conditions are still possible. Specifically if LocalParticipant.setSourceEnabled (via setCameraEnabled/setMicrophoneEnabled) is called concurrently, there is a race between this check and adding the publication here (video) resp here (audio)
To Reproduce
Call setMicrophoneEnabled concurrently. An over-simplified version would be
Describe the bug
We enable/disable camera and microphone of the local participant in a callback whenever our call state changes. Sometimes we experienced duplicated audio and/or video streams. It turns out, while dart is single-threaded, due to its async nature, race conditions are still possible. Specifically if LocalParticipant.setSourceEnabled (via setCameraEnabled/setMicrophoneEnabled) is called concurrently, there is a race between this check and adding the publication here (video) resp here (audio)
To Reproduce
Call setMicrophoneEnabled concurrently. An over-simplified version would be
A workaround is of course to lock accesses to setSourceEnabled from outside the SDK, but it would be nice if the SDK could handle such cases
Expected behavior
One audio stream is published
Platform information