Date: prev next · Thread: first prev next last
2020 Archives by date, by thread · List index

Hi Emiliano, *,

On Sun, Mar 15, 2020 at 2:49 PM Emiliano Vavassori
<> wrote:
Il 13/03/20 16:22, Florian Effenberger ha scritto:
Disabling video did not help.

I don't know if that can help, but what came to my mind is that the
default settings for video in Jitsi is HD. Since there are no specific
options for the audio, I would expect that this quality settings could
have some impacts on the audio part of the stream as well. Decreasing
audio quality a bit shouldn't be an issue.

We had a little loadtest today to get some more insights (thanks to
all who joined in!) - and the issue we discovered is not load on the
server (at least not with the increased resources assigned to the VM)
or the server's bandwidth, but rather the load on the client machines
with many participants.

Android app didn't cope at all, and I got the stretched audio and huge
delays and unresponsive UI. On laptop with one instance connected in
chrome, and another one in firefox it didn't affect my listening
experience, but there were audio-problems when I was talking -
CPU-load on the laptop was maxed out, and after closing the firefox
instance others could hear me again without artifacts. So that is in
line with Drew's feedback - as long as your machine can keep up, you
should not have any problems hearing others. And when it is just at
the edge of managing the load, it is the sending that causes problems

I'd propose
- assinging more resources to the VM -> Cloph, can you have a look?

Done - machine has now double the vcpus compared to before and didn't
max out during our testing today, so while it might have been tight in
the last meeting, it should not be a problem with future ones.

- finding out if there was any major spike in traffic on the VM recently
-> also Cloph, can you have a look?

Today's test also involved using video streams (while still waiting
for more participants to join) - and network traffic stayed below
200Mbps outgoing for the VM, and other VMs on the same hypervisor also
didn't have much outgoing traffic, so we're well within Gigabit
connectivity limits

- have a fallback plan to have a proper meeting

That's the difficult part.

Yeah, that's a little tricky.. :-) So current recommendations to
reduce load on your system:
* Avoid android app when joining call with many participants - the
app/your phone likely won't be able to cope.
* Use audio-only mode, don't send any video streams and don't request
any video streams
  This can be done by using Settings → Manage Video Quality and
picking [x] low bandwidth or by joining with

Smaller improvements can be had by not using grid view, but the
default with the strip at the side, and likely by hiding the list of
People having connection issues should monitor their local system
resource usage/whether CPUs are maxed out and the problems are caused
by that.

Now back to my findings. I've invested some hours of my time (and I will
do again this afternoon, if possible) on learning more on Jitsi and its
guts. My primary source of information at the moment are this video:

And the documentation bits on the GitHub project:

My first take on this is that cascading (in the sense of deploying
multiple servers in different parts of the world) would not solve the
participants number issue per se;

Yes - as far as my understanding of the problem is so far: won't help
for single meetings with lots of participants. Is more suitable for
achieving lower latency in regional meetings meetings - but once
people from different regions join that benefit is gone – or to scale
up for lots of simultaneous meetings with few people.

We have already pointed out the two most probable source of bottlenecks:
* Network

yep, but looks like those seem to be a problem on the client :-)


To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
Privacy Policy:


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.