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.
pulse-messages.txt.gz
Description: application/gzip
_______________________________________________ pulseaudio-discuss mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
