[pulseaudio-discuss] How to control latency with CLI?

[Tanu Kaskinen]

On Fri, 2017-10-13 at 19:09 +1030, Steven Wawryk wrote:
> Today I noticed that there seems to be about 5minutes delay in 
> module-remap-source on the workstation rather than in module-loopback on 
> the embedded system.
> 
> With the following CLI script items (selecting 1 of the 12 channels of 
> digitised audio from the embedded system):
> 
>      ...
> 
>      load-module module-null-sink sink_name=rtp_in_sink1 
> sink_properties=device.description=RTP_in1 format=ulaw rate=8000 
> channels=12 
> channel_map=aux0,aux1,aux2,aux3,aux4,aux5,aux6,aux7,aux8,aux9,aux10,aux11
>      ...
> 
>      load-module module-rtp-recv sink=rtp_in_sink1 
> sap_address=224.0.0.81 latency_msec=10
>      ...
> 
>      load-module module-remap-source source_name=voip_source 
> master=rtp_in_sink1.monitor 
> source_properties=device.description=VoIPSource format=ulaw rate=8000 
> channels=1 master_channel_map=aux4 channel_map=front-left remix=no
> 
>      ...
> 
> ... and observing with pavucontrol, when I tapped or spoke into the 
> microphone, there was signal with no noticeable delay at rtp_in_sink1 
> and rtp_in_sink1.monitor, but the signal could not be seen on 
> voip_source until about 5minutes later.  I can't see any obvious reason 
> in the module-remap-source source code.
> 
> I will investigate further on Monday (including logs), but have I messed 
> up the above CLI statements?

I don't see anything wrong with the CLI commands.

The latency in module-remap-source is weird. The module itself doesn't
do any buffering. module-remap-source connects to the master source
using a pa_source_output, and pa_source_output contains
delay_memblockq, which is a buffer. Maybe the delay_memblockq is
involved in the huge latency? The purpose (or at least one purpose) of
delay_memblockq is to keep enough data buffered in monitor sources to
deal with the possibility of data getting changed in the unplayed
portion of the sink playback buffer. The sink in your case (or in any
other case) doesn't have a playback buffer of 5 minutes, so if the
delay_memblockq holds 5 minutes worth of data, there's some bug. Maybe
adding some extra logging to pa_source_output_push() will shed some
light on the matter.

-- 
Tanu

https://www.patreon.com/tanuk