[pulseaudio-discuss] Tunnel vs direct connect to remote PA server - tunnel unreliable

[Matt Garman]

I posted recently about this under the subject "Networking and volume
control", but thought I'd start a new thread, as my focus is now less
about volume, and more about getting reliable playback on a tunnel.

Here's the setup: I have PulseAudio running on a Raspberry Pi,
intended to be a music server for my office workstation/PC.

The problem I'm having is: everything seems to work fine, as expected,
when I direct connect from my PC to the RPI using PULSE_SERVER.
However, on my workstation, I regularly need to switch between the RPI
server and local sound devices, so direct connect is not appropriate
for my use case.  But I'm having issues with reliable playback when
using a tunnel.

If I play a wav file using paplay prefixed with PULSE_SERVER (i.e.
direct connection), then things seem to work as expected:

$ PULSE_SERVER=dietpi-music paplay --verbose song.wav
Opening a playback stream with sample specification 's16le 2ch
44100Hz' and channel map 'front-left,front-right'.
Connection established.
Stream successfully created.
Buffer metrics: maxlength=4194304, tlength=352800, prebuf=349276, minreq=3528
Using sample spec 's16le 2ch 44100Hz', channel map 'front-left,front-right'.
Connected to device alsa_output.default (index: 0, suspended: no).
Stream started.
Time: 1.126 sec; Latency: 2005612 usec.

The last line is interesting: here the "Time" counter keeps going up,
and the latency changes constantly, but stays approximately the same.

Now if I play the same file without the PULSE_SERVER prefix, i.e. by
using a tunnel, then things look like this:

$ paplay --verbose song.wav
Opening a playback stream with sample specification 's16le 2ch
44100Hz' and channel map 'front-left,front-right'.
Connection established.
Stream successfully created.
Buffer metrics: maxlength=4194304, tlength=352800, prebuf=349276, minreq=3528
Using sample spec 's16le 2ch 44100Hz', channel map 'front-left,front-right'.
Connected to device tunnel.dietpi-music.local.alsa_output.default
(index: 19, suspended: no).
Stream started.
Time: 0.000 sec; Latency: 108373832 usec.

I do get playback.  But in this case, that Time counter is stuck at
0.000 seconds (it never increments).  Furthermore, the Latency counter
keeps going up (strictly increasing).  The final number when the song
playback finishes is approximately the same as the length of the song
(309346656 usec).

The other things I've observed: playback of a YouTube video in
Firefox, which uses PulseAudio.  It works completely fine when
direct-connected.  But when using the tunnel, sometimes playback
completely hangs (like a network timeout); sometimes the video will
play, but after a random amount of time, it will stop, or reset itself
back to the beginning.

I have this program "Transcribe!", which is gstreamer based.  One
feature this program has is a live waveform of the left and right
channels, which updates in real-time as the song plays back. When I
use this program with PULSE_SERVER (i.e. direct-connect to the RPI) it
works as expected.  But when using the tunnel, I do get playback, but
that waveform is static, not updating in realtime as it's supposed to.

All these things together make me think that the tunnel appears to be
a "one way" construct.  It looks like I can send data to the tunnel
(and get playback), but it seems like no data comes back.  I assume
the PulseAudio protocol is two-way, obviously you need to send audio
data to the server, but presumably the server needs to send back
acknowledgements and other status information.

Thanks!
Matt