JitsiTrack.setEffect brokes audio in Firefox remote participant

[bukharin]

Description

When start screen sharing in Chrome with unified plan with audio remove participant with Firefox stops hearing Chrome participant

Reproduces on meet.jit.si

Expected Behavior

Firefox participant should not stop hearing Chrome participant

Steps to reproduce

Create conference with FF and Chrome participant. On Chrome start screen sharing with enabled "local audio" checkbox. After sharing FF participant does not hearing Chrome participant

[saghul]

Ping @jallamsetty1

[jallamsetty1]

@bukharin I can't seem to reproduce this issue on meet.jit.si. Are you still reproducing it there ? What version of chrome are you on and what on what platform ? Is this issue specific to FF only, i.e. only FF is not able to hear the shared audio while chrome clients can ? I don't see how that is possible, the audio stream sent by the client doing the audio share is a mixed audio stream (mic audio if unmuted + tab audio) but it is still a single audio stream.

[bukharin]

@jallamsetty1 yes,

let me show how to reproduce on single local machine.

1. Open same conference in FF and Chrome, like meet.jit.si/lalala. I am using WIndows 10, FF 91 and Chrome 92
2. Turn OFF microphone in FF and ON in Chrome. You will hear yourself, because FF will play audio from Chrome
3. Share screen in Chrome with Audio access

After that you won't hear yourself becase FF stop to play Chrome audio track.

I'm also reproduce this issue if I replace audio track in Chrome like this:

await jitsiConference.removeTrack(oldAudioTrack);
await jitsiConference.addTrack(newAudioTrack);

But this call works fine:

await jitsiConference.replaceTrack(oldAudioTrack, newAudioTrack);

[jallamsetty1]

@bukharin Are you able to reproduce this issue when the Chrome and Firefox endpoints are running on two different machines ? Firefox and Chrome do not share audio/video devices properly, i.e., if Firefox grabs the device first, it becomes unavailable for chrome on some platforms. The fact that replaceTrack works while removeTrack->addTrack doesn't kind of confirms that its not in our code.

[bukharin]

@jallamsetty1

Are you able to reproduce this issue when the Chrome and Firefox endpoints are running on two different machines ?

Yes, tested on Windows and MacOC

if Firefox grabs the device first, it becomes unavailable for chrome on some platforms.

To reproduce this issue you don't need access to devices in FF, just deny access when FF asks.

[bukharin]

@jallamsetty1 are you able to reproduce this issue?

Chrome 93 by default share audio if user select single tab for screensharing. This problem will apper more often now.