[pulseaudio-discuss] Chopped sound when using module-loopback with module-tunnel-sink

[Zrin]

Hey folks,

when I use module-loopback to connect audio input (line-in) to a sink
provided by
module-tunnel-sink, I get chopped sound on the receiving side. The sound
output is
missing parts and it gets worse over time. I've made following
observations:

- typical debug output (sending side) that correlates with this problem is
...
D: [pulseaudio] module-loopback.c: Should buffer 0 bytes, buffered at
minimum 0 bytes
D: [pulseaudio] module-loopback.c: [usbol] Updated sampling rate to 44100
Hz.
D: [pulseaudio] module-loopback.c: Loopback overall latency is 149.26 ms +
10.50 ms + 1.01 ms = 160.77 ms
...
this is repeated in the output and the chopping gets worse with the time

- debug output on the receiving side during output
...
D: [alsa-sink-USB Audio] memblock.c: Pool full
D: [pulseaudio] memblock.c: Pool full
D: [pulseaudio] memblock.c: Pool full
D: [alsa-sink-USB Audio] memblock.c: Pool full
D: [alsa-sink-USB Audio] memblock.c: Pool full
... repeated ...
D: [alsa-sink-USB Audio] memblock.c: Pool full
D: [alsa-sink-USB Audio] ratelimit.c: 25 events suppressed
D: [alsa-sink-USB Audio] alsa-sink.c: Wakeup from ALSA!
D: [alsa-sink-USB Audio] alsa-sink.c: Wakeup from ALSA!
D: [alsa-sink-USB Audio] flist.c: pulsecore/memblockq.c: list_items flist
is full (don't worry)
D: [alsa-sink-USB Audio] flist.c: pulsecore/memblockq.c: list_items flist
is full (don't worry)
... repeated ...
D: [alsa-sink-USB Audio] flist.c: pulsecore/memblockq.c: list_items flist
is full (don't worry)
D: [alsa-sink-USB Audio] ratelimit.c: 73 events suppressed
D: [alsa-sink-USB Audio] flist.c: pulsecore/memblockq.c: list_items flist
is full (don't worry)
...

- chopping gets worse over time, and within few minutes there is no
(hearable) sound output any more

- the chopping depends on latency_msec passed to the module-loopback, but
it is always there
and gets worse over time. (Lower latency gives less (hearable) chopping at
the start.)

- at the same time, I can paplay or play-sample in parallel to the output
from module-loopback
to the same sink without problems

- If I suspend the sink on the receiving side and the resume it again,
then there
is huge latency (the sending side seems to be unaware?), but for some time
the sound
output is without (AFAIC hear) distortions. module-loopback outputs (debug
log) messages
about sampling rate adjustment. After some time, the latency gets reduced,
but then
D: [pulseaudio] module-loopback.c: Should buffer 0 bytes, buffered at
minimum 0 bytes
appears again and the sound gets chopped.

- local loopback from audio-in to audio-out is ok


The setup consists of two almost identical systems with a minimal Debian
testing install.
I've compiled PA 4.0, sources are from Debian unstable.
There is no "desktop environment" - no Gnome or similar.
I've tried to run PA both as system instance and user's instance - both
with root privileges -
there is no difference.

Examples of full debug log:
Client side (sending): http://pastebin.com/xwP4Qhwa
Server side (receiving): http://pastebin.com/U3h55jmN
Local loopback: http://pastebin.com/S7VT8UZ7

Config (both sides):
log-level=debug
exit-idle-time = -1

Init (both sides):
load-module module-udev-detect
load-module module-native-protocol-unix auth-anonymous=1
load-module module-native-protocol-tcp auth-ip-acl=192.168.0.0/24
.ifexists module-dbus-protocol.so
load-module module-dbus-protocol access=local
.endif
load-module module-always-sink
load-module module-suspend-on-idle
load-module module-cli-protocol-unix


I'm testing PA for a possible use in an embedded solution with several
(for now two) nodes.
The current idea is to use module-tunnel-* and module-loopback to connect
various audio
inputs and outputs and then set volume or mute/unmute and/or suspend and
resume to get
desired connections - simple switching and mixing.

Zrin