1480211 - Google Meet has huge audio latency

Status: RESOLVED FIXED

(Core :: WebRTC: Audio/Video, defect, P2)

Description

[Dzmitry Malyshau [:kvark]]

When using Google Meet, the audio latency ranges in seconds. I've seen (heard?) cases of it being 10 seconds and more, which makes any conferencing totally unfeasible. Notably, the video doesn't appear to suffer, so I end up seeing people talking and trying to read from their lips.

Might be related to https://bugzilla.mozilla.org/show_bug.cgi?id=1430827

Comment 1

[Dzmitry Malyshau [:kvark]]

Good news, I'm no longer experiencing the issue with "Firefox 64.0a1 (2018-10-15) (64-bit)"

Comment 2

[Andrey]

I am still seeing this issue with both Google Meet and the Vidyo web RTC product as of 67.0.4 (64-bit). Seems to be CPU load related, starts fine, but the latency slowly increases as the call goes on. I've personally seen up to a 5 second delay in audio. I'll put more details in 1430827

Comment 3

[Paul Adenot (:padenot)]

Andrey, can you try a nightly 0, and report back here if you still see an issue? I've done quite a few changes to try to fix this, I landed them last week.

Comment 4

[Andrey]

Attachment: attempt 3 crash logs

Hi Paul,

Thanks for putting work into this issue! Sadly as of `69.0a1 (2019-07-03)` I'm still seeing issues. I'm reproducing this by joining the same call from 2 windows, one of them private.

Attempt 1: Saw 1 second audio latency immediately after the 2nd window joined the call, which within 30 seconds increased to 2 seconds.

Attempt 2: I ended the call and refreshed the pages. Audio didn't appear to be working, but in Google Meet the "test speakers" button played fine, and everything looked configured correctly to me in `pavucontrol` and was showing the mic was picking up sound. I ended the call on one side, then heard myself speaking from a while ago and saw `pacmd` was reporting 45 second sink-input latency.

Attempt 3: The call I ended, I rejoined. I could hear audio, but the page wasn't rendering properly, and shortly after Firefox crashed with the following as terminal output where I had executed `./firefox` from:

```

Comment 5

[Andrey]

Hi Paul,

Thanks for putting work into this issue! Sadly as of 69.0a1 (2019-07-03) I'm still seeing issues. I'm reproducing this by joining the same call from 2 windows, one of them private.

Attempt 1: Saw 1 second audio latency immediately after the 2nd window joined the call, which within 30 seconds increased to 2 seconds.

Attempt 2: I ended the call and refreshed the pages. Audio didn't appear to be working, but in Google Meet the "test speakers" button played fine, and everything looked configured correctly to me in pavucontrol and was showing the mic was picking up sound. I ended the call on one side, then heard myself speaking from a while ago and saw pacmd was reporting 45 second sink-input latency.

Attempt 3: The call I ended, I rejoined. I could hear audio, but the page wasn't rendering properly, and shortly after Firefox crashed (logs attached)

Comment 6

[Andrey]

Argh, sorry for the double post (adding the attachment submitted the entire comment).

I just wanted to also add that with the nightly, I saw latency decrease at times, which I think is new behaviour. It never went back down to reasonable levels however.

Comment 7

[Andrey]

Tried again today with 69.0a1 (2019-07-04), and noticed some different/better behaviour, possibly because of a slightly different testing method. No crashes today either.

Today, when I joined the Meet call from the 2nd window, I did NOT grant microphone/camera permissions for the 2nd instance (I can't remember exactly what I did yesterday). Initially, the audio latency for both sessions was in the 20/30ms range. I then opened a new tab and played some 4k Youtube videos, and never saw the audio latency of either session go far above 150ms (which is very usable). After the load was removed however, I did not see the latency decrease back to original levels (bounced around between 120 - 150ms). At this point, I granted microphone permissions to the 2nd instance and immediately saw audio latency jump to ~400ms, and then ~2700ms soon after (and the latency seemed to be synchronized for both sink-inputs). Not sure this is a usage pattern that matters, but figured I'd point it out.

Comment 8

[Andreas Pehrson [:pehrsons]]

Yes, we are very vulnerable to multiple open input streams on linux. Since we only allow one concurrent open stream per window it is luckily not a very frequent real-world scenario. I mostly hit this when testing (using multiple tabs to connect to a room or some such), and cases where I do a call with other people work pretty well since there's only one open stream. Though note we are still working to improve this.

Comment 9

[Paul Adenot (:padenot)]

I don't think this can happen today, I fixed this in https://github.com/mozilla/cubeb-pulse-rs/commit/3a748a2df25658f1c8c5a475b9dd2ae4561b174b.