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

[Steven Wawryk]

>> 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.
>
> I've been trying to add trace logging to the code, but I haven't been 
> able to do it so far.
>
> I've only got limited ability to do stuff like that on the test 
> workstation, because it's a dedicated test machine used by several 
> people and it doesn't have a development system on it. I'm not really 
> free to just install and uninstall stuff on it.
>
> I have downloaded the PulseAudio sources onto my (separate) 
> development machine and built with:
>
> ./bootstrap.sh
>     make
>
> I can't do "sudo make install", because it needs to go on the other 
> machine.  I've tried (after saving the original libraries) just 
> copying the relevant dynamic library onto the test machine, but it 
> breaks PulseAudio.  I've tried copying all binaries (also after 
> saving) and dynamic libraries and it also breaks PulseAudio.  The 
> errors I get in syslog are:
>
>     Oct 23 06:54:30 mm1 pulseaudio[2823]: [pulseaudio] 
> module-x11-publish.c: PulseAudio information vanished from X11!
>     Oct 23 06:54:30 mm1 alsactl[3080]: ALSA lib 
> conf.c:3357:(snd_config_hooks_call) Cannot open shared library 
> libasound_module_conf_pulse.so
>     Oct 23 06:55:43 mm1 alsactl[2072]: ALSA lib 
> conf.c:3357:(snd_config_hooks_call) Cannot open shared library 
> libasound_module_conf_pulse.so
>     Oct 23 06:55:45 mm1 /usr/lib/gdm3/gdm-x-session[2699]: 
> /usr/bin/pactl: error while loading shared libraries: 
> libpulsecommon-8.0.so: cannot open shared object file: No such file or 
> directory
>
> I don't think the ALSA errors are related.The last error is misleading 
> because:
>
>     ls -als /usr/lib/x86_64-linux-gnu/pulseaudio/
>     total 1320
>     drwxr-xr-x   2 root root   4096 Oct 18 06:23 ./
>     drwxr-xr-x 118 root root 118784 Oct 23 05:10 ../
>     -rw-r--r--   1 root root 504440 Jan  6  2017 libpulsecommon-8.0.so
>     -rw-r--r--   1 root root 669320 Jan  6  2017 libpulsecore-8.0.so
>     -rw-r--r--   1 root root  43768 Jan  6  2017 libpulsedsp.so
>
> Using ldconfig doesn't help.  I'm at the limit of my system hacking 
> ability and seem to be stuck at the moment.
>
> Both machines are ubuntu 16.04 LTS installations, but the test machine 
> is a very cut-down version of it.

One thing I have just noticed is that the libraries in the test machine 
binary installation (including libpulsecommon-8.0.so) are in different 
places than the "libdir" specified in the *.la files from the src/ 
directory of the source package.

I'll chase this up tomorrow.