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