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