Jitsi-meet: Sometimes participants can't hear other participants

[jonnius]

Description

Sometimes some participants can't hear some other participants. Some findings:

• occurs more often in meetings with many participants (does not seem to occur with 4 participants, occurs a lot with >=7 participants)
• does not happen between users with camera enabled
• is not necessarily bidirectional (A might hear B, while B does not hear A)
• workarounds
  
  
  
  • in most cases one can work around the issue by toggling the camera
  
  
  • in some cases one can work around the issue by reloading the page
  
  
  • in some cases none of the workarounds above helps
  
  
• issue seems to be around for years already, as it might be a duplicate to the closed issues #1278 and #641

Current behavior

There is an audio-only meeting with n>7 participants. Some participants cannot hear all other participants, e.g. participant 4 cannot hear participant 3 and 7.

Expected Behavior

Every participant can hear every other participant.

## Possible Solution

Steps to reproduce

Start a Jitis Meeting with as many users as possible, only enable Audio and try to speak to each other.

Environment details

Version: jitsi-meet v1.0.4101-1
Browsers tested: Chrome, Firefox on Win10 and Ubuntu 16.04

[rettichschnidi]

Pretty sure this is related to #4758

Also, other users (including me) have the same problem:

• https://community.jitsi.org/t/jitsi-users-use-meet-jit-si-with-many-users/13187
• https://community.jitsi.org/t/not-everyone-hear-all-participants/23986
• https://community.jitsi.org/t/meet-jit-si-app-meeting-participants-end-up-in-two-separate-meetings/23253

[damencho]

Is Firefox involved?

[rettichschnidi]

Yes
We could test again without Firefox, but it is very unlikely that we can get all our users to not use Firefox.

[damencho]

We are working on improving Firefox experience, but that is for now. Firefox sometimes does not send or receive any streams ... and leads to problems. That's why we put a notification when you are on Firefox and using meet.jit.si, to warn people.

[jonnius]

We experienced the issues also on Chrome.

We just updated to jitsi-meet v1.0.4296-1 and disabled Peer-to-Peer connections. On a test with 10 participants the issue did not occur on Chrome any more. On a test with everyone on Firefox 1 out of 10 could not hear some others.

[damencho]

We will update very soon stable.

[Jasper-Ben]

We are experiencing the same issue with 9 people in the same room, even between users using chromium-based browsers. We also tried to connect with all participants using said browsers (which I'm 90% sure we archived) and issues still persists. So maybe not just a firefox issue?

[jonnius]

We did as well before updating. Which version are you using?

[Jasper-Ben]

the latest jitsi-meet package currently available from jitsis debian repository: jitsi-meet/stable,now 1.0.4101-1

It used to work when microphone and cam where enabled by default when joining a room during our testing phase. But since we disabled that in the jitsi server settings it is completely unreliable. So for me it seems the issue is related to the (lack of) video or audio streaming.
Out of privacy concerns I am unfortunately unable to reactivate said settings to see if it makes any difference, as 20+ users in our company now expect it to be disabled by default.

Also I was able to reproduce the issue in a two-participants room (although one was using firefox), so this issue does not seem to be bound to the number of users in a room as suggested in the initial report. There might have been users in other rooms at that time though, so it might be a question of how many users are connected in general, regardless of room.
The two of us then switched to my private jitsi instance without disabled devices by default and it worked as expected.

[jonnius]

You are using the very same version we experienced this issue a lot with. After updating to the 4296 build we did not see this issue on Chrome any more. We also have mic and cam disable by default.

[Jasper-Ben]

thanks for the info! will try the nightly branch then and install the same version. I will report back, if we continue to experience issues.

[jonnius]

We just had a meeting with 11 participants, all on Chrome, where one participant could not be heard by some others. Reloading the page for the one fixed it. Build: 4296

[saghul]

Thanks for chiming in @jonnius !

[Jasper-Ben]

We just had a test meeting with 20 participants (all on chromium) and it worked flawlessly. Also build 4296. Seems to be fixed :+1:

[Jasper-Ben]

P.S.: we actually had one minor issue with a participant using Vivaldi. After he switched to chrome it worked as expected. We didn't investigate further but my guess would be that Vivaldi might use an old chromium base. Just something to be aware of.

[Isolator70]

Hello, using Jitsi sporadically, but due to Corona crisis now more often.
Today I had a 2 person call between Chromium@LinuxMint_18.3_PC and Jitsi App@Android. Everything fully up-to-date. After some minutes it was not possible anymore for the Person at Android to hear the Person from the PC.
At the PC one could observe, that the microphone indicator did not react to volume put into the microphone.
Going to the settings of Jitsi in Chromium browser one could see "Permission not granted" for the audio stuff (although it was done and checked at the beginning of the meeting).
Checking the audio permission in Chromium itself, camera and audio stuff was enabled.
After closing and restarting the meeting everything was fine again, but broke down some minutes later again.
Do you think it is the same issue or shall I create another ticket?
Thank you

[Isolator70]

Okay, I have to add following information: Today I was in a 35 minutes video call with up to 17 participants, most of them without activated camera, 5 with camera activated. I'm sure most of them were on Windows machines, 1 maybe on Mac, 1 with iPhone, 1 with Android,
From my point of view, everything ran perfect - I couldn't see the issue of yesterday again! So I will observe the behaviour if it is random.

[keinstein]

Hi, on March 27th, we had a meeting with 3 people on meet.jit.si (I don't know which version they run). All using web browsers and we had the problem that the 3rd person connected but did not receive any audio or video. After he managed to setup his audio and video settings, person 1 could hear both 2 and 3, 2 could hear only 1, 3 only 2. So every one was streaming something to someone. But somehow the streams stopped working.

[real-or-random]

We observed this today in 3-person call on 4384. A Jigasi/SIP peer couldn't hear an electron peer. Everything else worked. "Restarting" the stream by changing the microphone device on electron and changing back fixed this.

[thomaswucher]

We also observed this problem today on a self-hosted instance using the latest official docker images and the master branch of docker-jitsi-meet (0177765f) in a conference with 5 participants.

All participants were using Firefox. The ones which had video enabled didn't experience the problem, those with audio only could sometimes not hear all other participants. For those experiencing problems, reconnecting sometimes helped.

[Jasper-Ben]

All participants were using Firefox.

Hi Thomas, as things stand right now I'd suggest you enforce a policy of chromium based browsers only, as issues with Firefox are still being resolved. And although the related issue https://github.com/jitsi/jitsi-meet/issues/4758 is marked as resolved, this to my understanding only fixes any issues on the jitsi side of things. There are still open upstream issues in Firefox (linked at the bottom of the thread).

We enforce our chromium only policy by changing the following in the interface_config.js:

OPTIMAL_BROWSERS: [ 'chrome', 'chromium', 'nwjs', 'electron' ],
UNSUPPORTED_BROWSERS: ['firefox','safari'],

This causes users trying to open jitsi with a Firefox or Safari Browser to be prompted to install the latest Google Chrome. For anyone who doesn't want to use Chrome out of privacy concerns we recommend using Chromium or Brave, as they are both open-source and (for the most part) do not include the Google tracking stuff.

[jonnius]

Things should improve with Firefox 76.

[btsimonh]

I'm currently investigating a problem with jitsi which sounds very much like this and previous descriptions.

We had 3 people on the call, All Chrome 81.0.4044.129 on windows 10 64 bit using embedded jitsi from 'https://meet.jit.si/external_api.js'. - So this may highlight that it's not a firefox only issue, and hopefully may provide some more pointers....
Certainly the 'unheard' person was sending audio, because they were heard by another, yet not heard by the third person. The 'unheard' person could hear the person who could not hear them.... The person who could not hear them could hear the other person.

Prior to integrating, we tested 7-10 calls using meet.jit.si for bulk family calls (always with video?), and apart from once on MAC which didn't screenshare whatever we did (it had previously), we had no (apparent) problems.

I find this in the browser log as a yellow:
Logger.js:154 2020-05-04T15:56:33.440Z [modules/statistics/AudioOutputProblemDetector.js] A potential problem is detected with the audio output for participant 02b26f22, local audio levels: [null,null], remote audio levels: undefined

If I separately join the room using meet.jit.si/roomname, then I too could hear the person, but not through the embedded version (could i just have been lucky?). But this was not an extensive test (3 times, it worked).

I start all the instances like this:
(i.e.
video muted; which could be related/
these ones because they mess with my audio mojo (i.e. I'm also recording quality audio from the mic, and these seem to mess with Chrome's global mic gain).
enableNoisyMicDetection:false, - I don't need or want the 'pip-pip-pip' indication by audio...
enableNoAudioDetection:false,
enableTalkWhileMuted:false,
disableAudioLevels: true,
)

            let config = {
              enableNoisyMicDetection:false,
              enableNoAudioDetection:false,
              enableTalkWhileMuted:false,
              disableAudioLevels: true,

              // whole room by creator?
              //startAudioOnly:true,
              startWithAudioMuted: true,
              // only this person
              startWithVideoMuted: true,
              enableCalendarIntegration: false,
              disableThirdPartyRequests: true,
              disableRecordAudioNotification: true,
              //testing:{
                //noAutoPlayVideo:true,
              //},
              //chromeExtensionBanner: {},
              disableInviteFunctions: true,
              disableRemoteMute: true,
            };

            let interfaceConfig = {
              DISPLAY_WELCOME_PAGE_CONTENT: false,
              MOBILE_APP_PROMO: false,


            };

            this.jitsi_api = new JitsiMeetExternalAPI('meet.jit.si', {
              parentNode: this.$refs['putithere'],
              roomName: this.settings.roomName,
              configOverwrite: config,
              interfaceConfigOverwrite: interfaceConfig,
            });

it's important I work around this in the very short term; any ideas?

Simon

[Jasper-Ben]

video muted; which could be related/

In my experience the issue described here only occurs when disabling audio on entering the room.
So changing startWithAudioMuted: true, to startWithAudioMuted: false, might be a short term workaround?

Other than that, I cannot really help as I am unfamiliar with the api.

[btsimonh]

something else; watch out for
The AudioContext was not allowed to start. It must be resumed (or created) after a user gesture on the page. https://goo.gl/7K7WLu
I think this prevented one of my jitsi clients from starting audio?

[tomkel]

I still have this bug in rel 4548. In a call with ~15 people

[luixxiul]

I still have this bug in rel 4548. In a call with ~15 people

As this issue has been closed and the thing has been changed since then, there is actually nothing actionable here. You are expected to open a new issue, with steps to reproduce the error, server / client information, etc.

[dandv]

DISPLAY_WELCOME_PAGE_CONTENT: false,

@btsimonh, I see you've configured DISPLAY_WELCOME_PAGE_CONTENT. Have you figured out what it does?

[tomkel]

@luixxiul That's easier said than done, it's an intermittent issue and it usually takes 10-15 clients before the issue starts happening. What kind of logs are needed and how do I get them?

[btsimonh]

@dandv - no. I just scanned the code for all possible configurations, and threw in random ones :).
@tomkel - I regularly have sessions with 3-4 clients where one client can't hear another, but others can hear them. It seems like a very complex issue, and probably multiple subtle issues. I'd love to have it happen when I have easy access to the clients in question, so I could try to diagnose, but it's rather difficult.
My application is a simple audio only intercom, and it fails regularly enough for me to be moving away from JitSi to a much simpler audio intercom over websockets with dedicated self-hosted servers. This also saves me a load of CPU, but costs me a load of dev time :(. I may retain JitSi, but only as a link to be used when screenshare is useful (it's a collaborative app, where some need help setting up).

[Nicramus]

something else; watch out for
The AudioContext was not allowed to start. It must be resumed (or created) after a user gesture on the page. https://goo.gl/7K7WLu
I think this prevented one of my jitsi clients from starting audio?

good point - in my case that was the problem