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

[Steven Wawryk]

Thanks for the response Tanu.

On 08/10/17 03:30, Tanu Kaskinen wrote:
> 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.
I've attached a compressed, filtered log with -vvvv supplied to 
PulseAudio.  There's nothing that jumps out at me to help find the 
source of the garbage.

>> * 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.
Both sender and receiver should be 8000Hz (but obviously not 
synchronised).  I'll try to verify there's no clock issue on the 
embedded platform.

>> * 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.
Thanks.  I will disable this.

>> * 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.
Looking into this, the user that's running this isn't in the pulse-rt 
group and pulseaudio binary isn't setuid root.  I'll fix this and give 
it another go.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pulse-output.txt.gz
Type: application/gzip
Size: 24592 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20171009/e0fd0ca8/attachment-0001.gz>