Bad audio quality and users dropping randomly, at ~25 users

Hi everyone,
we are hosting our own instance, using it for team meetings.
With 25 users we experience people dropping out of the call and audio quality issues.
People are able to login again, yet problems persist.

We run the following versions on ubuntu:

root@communication:~# apt list --installed | grep jitsi
    jitsi-meet/stable,now 2.0.4416-1 all [installed]
    jitsi-meet-prosody/stable,now 1.0.3992-1 all [installed,automatic]
    jitsi-meet-web/stable,now 1.0.3992-1 all [installed,automatic]
    jitsi-meet-web-config/stable,now 1.0.3992-1 all [installed,automatic]
    jitsi-videobridge2/stable,now 2.1-169-ga28eb88e-1 all [installed,automatic]

root@communication:~# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.4 LTS
Release: 18.04
Codename: bionic

The server we use is a standard DigitalOcean droplet:
Standard / 8 GB / 4 vCPUs

We only have about 50-60% utilization:

Users are all on laptops, mostly Win10 and some MBPs, with Chrome.

I also reduced the default resolution from 720 to 480 in the config.js.
Similiar seems to be happening in this thread, yet we seem to be more stable: Multiple Problems with Video and/or Audio Not Working in Calls on via browser
Should we try these URL parameters as well?


try add

the rendering of the blue “i am talking” dots cause frequent calculations and relayout of the GUI. by adding this configuration option my client CPU usage goes from 100% to 10% and audio quality is improved.


nice find :heart_eyes:

@xranby Do you mean add that without the #? Also, what config file is this?

I want to note that I too am having severe problems (like those described here and in Multiple Problems with Video and/or Audio Not Working in Calls on via browser ) once the number of users gets up to around 7 or 8, although I still have plenty of CPU and memory.

I was hoping to use Jitsi for the FOSS and privacy benefits, but I think we’re going to have to migrate to gotomeeting or some such.

It is the /etc/jitsi/meet/*-config.js file

// Audio

// Disable measuring of audio levels.
disableAudioLevels: true,

Try use the chrome browser inspect page -> performance tab analyser and check what is causing high CPU/GPU load on your machine. You may experience something different that cause your high load.

Open the chrome browser page inspector, switch to the Performance tab, then press record for about 5-20 seconds.

With the capture allows you to zoom using the scroll view and highlight sections of the capture with high CPU load and investigate what function calls cause the CPU load. The “flame graph” will reveal what scripting function is causing the high CPU/GPU load.

Please share a screenshot of the performance tab or a saved capture from the performance tab so that we can see what is happening on your machine.

Chrome profiling and evaluation tips:

We had a lot of problems too. Then we made a few changes.

The changes above was a night and day difference. We were suddenly able to hold a meeting with 20+ people without any problems. Major improvements. We’re running at around 40% CPU now. Probably memory could be a lot lower but we have enough memory on the host machine so just gave it more than enough. Maybe it’s the hardware encryption we were able to set for the VM that did the trick… Not sure. All I know is that we have a very good setup now. And we’ll just horizontally scale this when needed.


@PeterS Just a quick question, did you experience the issue related with access authority to microphone and camera on the latest unstable repository?

Didn’t receive any users complaining about this. You’re experiencing this problem? Users can’t select their camera or mic?

Exactly- that issue has been widely reported since a couple of days on the GitHub and I started to experience that too.

I’m going to check out the unstable repository. Thanks!

Thanks, thats an interesting hint. I will try that for sure!

Thank you Peter.

I changed the resolution to 480 in the config already.

For the change to the unstable repo, should this do the trick (just to confirm I am not messing around with the wrong ones):

Interesting one about the encryption. I will definitely look into this as well.

The unstable is just the master branch

what about disabling simulcast? any idea!
// Enable / disable simulcast support.
// disableSimulcast: false,

You better stay simulcast enabled, because it saves a lot of network bandwidth to you with Chromium based clients. And Firefox is ready to go.


it’s disabled or enabled by default? because it is commented on config.js
// Enable / disable simulcast support.
// disableSimulcast: false,

It is enabled by default.

thanks for you replay,
for firefox: I should enable it too?
// Enables experimental simulcast support on Firefox.
enableFirefoxSimulcast: false,

Since that issue is closed
I think that Firefox is support simulcast

You can do so (I did).
In that case simulcast will be explicitly enabled.

1 Like