[pulseaudio-discuss] How to control latency with CLI?

[Tanu Kaskinen]

On Tue, 2017-09-26 at 19:27 +0930, Steven Wawryk wrote:
> > > I'm trying to work out how to control latency with pulseaudio CLI scripts.
> > > 
> > > We're finding that latency varies between a few seconds to about 80 seconds.
> > > 
> > > We have a system which uses a dedicated embedded board for many channels
> > > of audio I/O.  Workstations
> > > connect with the I/O board using RTP over a network.
> > > 
> > > Pulseaudio 8.0 is used on both I/O board and workstation platforms, both
> > > using pulseaudio CLI scripts.
> > > Modules explicitly loaded include instances of module-rtp-send,
> > > module-rtp-recv, module-null-sink,
> > > module-remap-source, module-remap-sink and module-loopback.
> > > 
> > > This all works as far as it goes, but with VoIP (using 1 channel in each
> > > direction), we're finding
> > > that the latencies make it pretty much unusable.  Ideally, I need to be
> > > able to put a reasonable
> > > upper limit on total latency.
> > > 
> > > The link
> > > https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Developer/Clients/LatencyControl/
> > > provides instructions for use with the API, but I can't find much about
> > > controlling latency with CLI.
> > > A few modules appear to have latency-related parameters I can tweak, but
> > > this seems to be pointless
> > > because other modules are adding latency that I haven't worked out how
> > > to control.
> > > 
> > > Is there any way to do this?
> > 
> > If you're seeing 80 second latencies, I think the only place in which
> > that amount could accumulate is module-loopback. PulseAudio 11.0 has a
> > big improvement in the module-loopback latency regulation, so I
> > recommend upgrading.
> 
> Hi Tanu,
> 
> We've upgraded the I/O board (the platform with the module-loopback) to 
> use PulseAudio 11.1, but seem to be getting the same result.  Also tried 
> adding the latency parameters that are used by module-loopback, 
> module-alsa-sink, module-alsa-source and module-rtp-recv.  We've even 
> observed latencies of several minutes.
> 
> Using pactl list sinks/sources/sink-inputs/source-outputs, the biggest 
> latencies listed are in the tens of thousands of usec, so there doesn't 
> seem to anything that accounts for it.  This is true on the workstation 
> too.  I can't work out where the big latency is added.
> 
> There are some odd messages in the log (with -v).  I've attached the 
> compressed, filtered log ("grep pulse"):
> 
> * module-loopback seems to be "dropping" a lot of audio 
> ("module-loopback.c: Dropping 920177108 usec of audio from queue") and 
> "adding" a lot of silence ("module-loopback.c: Adding 920174784 usec of 
> silence to queue") to the "queue".

If module-loopback is adding 920 seconds of silence to its buffer, that
seems like the likely reason for the extremely high latencies. The code
that calculates this number seems to be getting garbage from some
input. I suggest adding more logging to the module-loopback code to
find the garbage source.

> 
> * sample rates are set to 8000 throughout to eliminate resampling as 
> much as possible, but there are runs of messages of type 
> "module-rtp-recv.c: New rate of 8871 Hz not within 2‰ of 8852 Hz, 
> forcing smaller adjustment" with ever-growing deviations from 8000Hz, 
> possibly suggesting some kind of numerical instability. Sometimes it 
> outputs "module-rtp-recv.c: Sample rates too different, not adjusting 
> (8000 vs. 10014)."

The log messages suggest that the RTP sender is sending too fast, but I
can't say for sure what's really happening.

> * every now and then, there's a "core.c: We are idle, quitting..." 
> message, and the daemon shuts down and restarts.

How are you starting PulseAudio? This happens when running PulseAudio
in the per-user mode and there are no clients for a while. You can pass
--exit-idle-time=-1 to disable this. There's also an option in
daemon.conf for doing the same. Normally module-systemd-logind is used
to prevent the daemon from exiting during the user login session, or
module-console-kit on systems that don't use systemd.

> * setting nice and RT scheduling seems to fail "core-util.c: Failed to 
> acquire high-priority scheduling: Permission denied" and "core-util.c: 
> Failed to acquire real-time scheduling: Success".

Apparently your system doesn't allow PulseAudio to reconfigure nice
values less than 0.

The error message about real-time scheduling seems to suggest that
there's some bug in set_scheduler(), since it doesn't set errno
correctly in your case.

>From your later mail:
> Any feedback on how I could better have presented this issue to motivate 
> people to help would also be appreciated.

I don't think there's anything wrong with the presentation. I just
haven't had time to read my emails.

-- 
Tanu

https://www.patreon.com/tanuk