[pulseaudio-discuss] pulseaudio-discuss Digest, Vol 77, Issue 47

[Steven Wawryk]

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>