1430827 - Pulseaudio actual latency is much higher than requested latency with WebRTC

Status: RESOLVED FIXED

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

Description

[Paul Adenot (:padenot)]

Re-filing of bug 1370598 because of a mistake.

We observe that sometimes, especially when CPU load is high, the latency reported by PulseAudio and experience by users is very high.

This bug is about figuring out why.

Comment 1

[Dzmitry Malyshau [:kvark]]

Can we bump the priority on this one? Conferencing (with Google Meet) is rather unusable because of this issue.

Comment 2

[Andrey]

+1 on increasing priority, still an issue as of version 67.0.4. I need to use Google Chrome now instead for all my video conferencing (which is a fair bit as a remote worker).

The behaviour I've seen in both Google Meet and the Vidyo WebRTC product, is that the call starts okay, but as time goes on, the audio latency grows bit by bit, sometimes reaching up to 5 seconds in a 30 min call. It does seem to be load related since both products make the CPU fans on my 4-core 6th gen Lenovo X1 Carbon spin like crazy. At first I blamed PulseAudio and considered switching to plain ALSA or JACK, but it seems Firefox now requires Pulse. It's worth explicitly noting that the audio latency never decreases once it has gotten bad.

I can recreate the issue pretty easily by creating a Google Meet and joining from two windows (one private one) and then playing a 4k YouTube video for a bit. I can then unmute the mic in one of the sessions and watch myself clap to see the obvious latency (confirming what pacmd reports). I can provide any debugging info requested, but I'm not an expert on Pulse or Firefox internals.

The audio latency from a short Google Meet call this morning:

╰─➤  pacmd list-sink-inputs | grep laten
	current latency: 92.54 ms
	requested latency: 25.01 ms
	current latency: 1433.40 ms     <----------------
	requested latency: 6.26 ms

Comment 3

[Alex Chronopoulos [:achronop]]

Thanks, Andreay for the details. Can you try using the latest Nightly. Bug 1429847 attempts to solve some of these issues and it is landed there.

Comment 4

[Paul Adenot (:padenot)]

Alex, it seems to be something else, I'm talking with Andrey in bug 1480211 already and he reports that it does not fix it.

Comment 5

[Paul Adenot (:padenot)]

When 1567457 lands, it's worth a shot to re-try. The patches there fixes it for me, and I could repro before.

Comment 6

[Andrey]

Looking good! With the latest nightly build (70.0a1 (2019-07-25)), I haven't yet been able to reproduce the issue.

Comment 7

[Mike Kaply [:mkaply]]

Can this be closed now?

Comment 8

[Andrey]

I'm still happy here. Haven't had audio latency issues in a long time :)

Comment 9

[Paul Adenot (:padenot)]

Ah yes, this works well now. Thanks for the reminder.

Comment 10

[Antoine "hashar" Musso]

I am wondering if this bug can be fixed for the ESR (68.9.0). It is rather bad experience, but maybe it does not affect that many persons.

If I got it right, the issue is fixed by https://github.com/djg/cubeb-pulse-rs/pull/42

bug 1430827 updates the whole library, but maybe the two commits can be cherry-picked for ESR?

Comment 11

[Paul Adenot (:padenot)]

Antoine, I understand that this is really annoying, but ESR doesn't get patches that are not security or stability fixes (explicit policy: https://wiki.mozilla.org/Release_Management/ESR_Landing_Process#What_should_land_on_mozilla-esr68.2Fmozilla-esr78). Next ESR is 78, and is being release on the 30th of June (about four weeks), so hopefully this is tenable until you can update.

Comment 12

[Antoine "hashar" Musso]

Paul, I was looking for the ESR policy last night and could not find it, thank you for the link.

I am very happy to learn the next ESR Is being cut soon, so indeed it is not worth the hassle of cherry picking around

Merci beaucoup!

Comment 13

[Antoine "hashar" Musso]

ESR upgrade from 68.9.0 to 78.5.0 from Debian fixed the audio latency (Google Meet notably was affected). Thank you!