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>
