I've compiled a list of possible approaches to getting something that
works, given this problem. I'm hoping that someone more knowledgeable
than me could give me some feedback about which ideas would be more
profitable uses of my time, given that I don't have a lot of time left
to find a fix/workaround/etc.
* Getting real-time scheduling working, starting with putting the user
into the pulse-rt group.
* Messing around with daemon.conf parameters (default-fragment,
shm-size-bytes, etc).
* Using the "phone" media.role property.
* Reducing the UDP multicast buffer sizes.
* Replacing module-loopback with a "null" module-echo-cancel or a
trivial home-made loopback module using the PulseAudio API.
* Some other suggestion?
Any help would be greatly appreciated.
Any feedback on how I could better have presented this issue to motivate
people to help would also be appreciated.
Thanks in advance.
Steve
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.
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.gz>
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
