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.


_______________________________________________
pulseaudio-discuss mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Reply via email to