>> 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.
