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

[Steven Wawryk]

>> 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".

* 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...
Name: pulse-messages.txt.gz
Type: application/gzip
Size: 42368 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20170926/44a76ac0/attachment-0001.gz>