Chrome/Chromium-83 unusably bad synchronization, Chromium-80 works perfectly

Is this a known bug and if not, where do I report it?

I had noticed previously, when Google Chrome bumped up to version 83 that meet.jit.si stopped working properly on various Linux desktop systems (Ubuntu, Debian GNU/Linux). In particular Google Chrome would cause the audio to come in AFTER the video. I could see someone clap and then count to three before hearing the sound! Around the same time, perhaps relatedly, the Chromebook version of Chrome appeared to be crashing with Jitsi

My workaround had been to use Chromium 80 on the GNU/Linux side and the Jitsi Meet app on the Chromebooks. That’s been great.

For security reasons, I recently upgraded to Chromium 83 on GNU/Linux and found that it too fails to run Jitsi: in fact, except occasional blips, it wasn’t even able to send or receive audio or video.

Chromium 83 outputs to stderr a lot of messages about TURN that Chromium 80 does not. Perhaps there is a bug in the UNIX implementation of Chromium’s tunneling or WebRTC? (I say “UNIX” because I know one Jitsi user on MacOS who had the bizarre audio after video latency problem with Google Chrome and switched to Firefox which worked fine).

The bug seems to be completely repeatable in tests I did between myself and one other person, both running the current stable version of Debian GNU/Linux and connecting over meet.jit.si.

  • Chromium 80 to Chromium 80 works beautifully with meet.jit.si
  • Google Chrome 83 to Google Chrome 83, the audio came after the video.
  • Google Chrome 83 to Chromium 80, the audio came after the video.
  • Chromium 83 to anything can neither send nor receive data

For reference, the exact versions being tested were:

$ google-chrome --version
Google Chrome 83.0.4103.116
$ chromium --version
Chromium 83.0.4103.116
Chromium 80.0.3987.162

The error message Chromium 83 is spewing (that Cr-80 doesn’t) are of this form:

[13304:39:0702/180335.347775:ERROR:stun_port.cc(308)] Port[b80c7500:audio:1:0:local:Net[wlan0:192.168.1.x/24:Wifi:id=1]]: UDP send of 258 bytes failed with error 11
[13304:39:0702/180335.655763:ERROR:stun_port.cc(308)] Port[b80c7500:audio:1:0:local:Net[wlan0:192.168.1.x/24:Wifi:id=1]]: UDP send of 258 bytes failed with error 11
[13304:39:0702/180335.656453:ERROR:stun_port.cc(308)] Port[b80c7500:audio:1:0:local:Net[wlan0:192.168.1.x/24:Wifi:id=1]]: UDP send of 258 bytes failed with error 11

Is this a known and reported bug? It’s clearly a bug in Chromium, but since it hasn’t been fixed, it seems only Jitsi is triggering it. Is there any workaround?

Thanks!

1 Like

I have a similar experience: around the time Chrome 83 was released the sound became very problematic. I have Debian Buster on all my systems so I have no idea if the OS-version is part of the problem. But for me it is a serious problem.

1 Like

I have no problem with chromium 83.0.4103.116-1~deb10u1 on Debian Buster.
Self-hosted Jitsi…

I suspect this may be because of the insertable streams and end2end encryption … We are working on that.

1 Like

Do you have the same problem if you install Chromium 80?

sudo apt install chromium{-sandbox,-common,}=80*

Very interesting, Emrah. What about using meet.jit.si?

How can I tell if insertable streams and end-to-end encryption are the issue?

By the way, Chromium 83 also uses vastly more CPU with meet.jit.si than Chromium 80 does. I wonder if part of the reason I’ve been having problems is because my CPU is pinned at max.

The result is terrible on meet.jit.si. No smooth video, no synchronized audio…
But I have no error message about TURN. I think this is because I’m not behind a corporate firewall and no need to TURN connection.

All problems disappeared when using firefox-esr 68.10.0esr-1~deb10u1

1 Like

So, it’s something wrong with meet.jit.si. Shoot. I’ve told a lot of people to use that server.

@damencho: I couldn’t find any flag for disabling insertable streams in Chromium 83. There is no good workaround for this as there are security problems with Chromium 80 and Firefox has its own issues with Jitsi. Could you please disable the insertable streams experiment on meet.jit.si ASAP as it is too buggy at the moment. Thank you. I very much appreciate the work you do and I look forward to true e2ee with Jitsi Meet someday.

There is an update for chromium on Debian Buster repo today. The new versions are:

chromium                 83.0.4103.116-1~deb10u2
chromium-common          83.0.4103.116-1~deb10u2
chromium-sandbox         83.0.4103.116-1~deb10u2

And everything is OK on meet.jit.si now
Maybe something has changed on the server side too.

So, I’ve been happily using Chromium 80 with meet.jit.si for a long time now but I figured I’d give 83 a try and unfortunately the bug is still there for me. One core of my CPU gets pinned to 100% usage even when no one else is in the room. I tested it with Google Chrome 85 and had the same issue.

@damencho Is there any way to disable insertable streams? (Preferably by default for Linux systems with Chrome <=85).

We made a change while ago and they are not used if you don’t enable e2ee

I’m speaking of meet.jit.si. Ever since the e2ee went in, it has been CPU intensive, so much so it is unusable on low-end equipment, when using Chrome for Linux. I believe that includes Chromebooks: the workaround I’ve been telling people is to run the Jitsi Android app, but not all Chromebooks can do that.