[pulseaudio-discuss] How to control latency with CLI?
stevenw at acres.com.au
Tue Sep 26 09:57:19 UTC 2017
>> 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
>> 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.
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".
* 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)."
* every now and then, there's a "core.c: We are idle, quitting..."
message, and the daemon shuts down and restarts.
* 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".
Note that references to "riu_card" and "multicodec" refer to the alsa
driver I wrote quite a long time ago.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 42368 bytes
Desc: not available
More information about the pulseaudio-discuss