Thanks for the response Tanu. On 08/10/17 03:30, Tanu Kaskinen wrote:
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.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.
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.* 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.
* 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.
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.* 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.
pulse-output.txt.gz
Description: application/gzip
_______________________________________________ pulseaudio-discuss mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
