Mopidy - Pulseaudio to RaspberryPI with module-tunnel-sink

General
1

Hi guys,

Thats my setup at home:

  • Server : Virtuell machine (Mint) with mopidy and pulseaudio
  • Client1: Rasperry in room wz with pulseaudio
  • Client2: Rasperry in room ku with pulseaudio

I wanted to stream music from the Server to these two clients with “module-tunnel-sink” and it works well.

Changings on the Server:
I changed the following line in the /etc/mopidy/mopidy.conf:

output = pulsesink device=sinks_combined

I add these lines in the system.pa:

load-module module-tunnel-sink server=192.168.1.17 sink_name=wz
load-module module-tunnel-sink server=192.168.1.30 sink_name=ku
load-module module-combine-sink sink_name=sinks_combined slaves=wz,ku
set-default-sink sinks_combined

Changings on the Client1 and Client2:
I add this line in the /etc/pulse/system.pa:

load-module module-native-protocol-tcp auth-anonymous=1

This setup works well to stream music from the Server to Client1 Client2.
BUT, if one Client is disconnected from the network, an error occurs on the Server:

Dec 16 07:39:28 Virtual-Machine pulseaudio[5724]: [pulseaudio] module-combine-sink.c: [ku] sample rates too different, not adjusting (44100 vs. 64038).
Dec 16 07:39:38 Virtual-Machine pulseaudio[5724]: [pulseaudio] module-combine-sink.c: [ku] Total latency of output is very high (14913.24ms), most likely the audio timing in one of your drivers is broken.
Dec 16 07:39:38 Virtual-Machine pulseaudio[5724]: [pulseaudio] module-combine-sink.c: [ku] sample rates too different, not adjusting (44100 vs. 108689).
Dec 16 07:39:38 Virtual-Machine pulseaudio[5724]: [pulseaudio] module-tunnel.c: Protocol error.

If the Client is reconnected the stream never come back. The only way is:

  1. Restart pulseaudio on the Client
  2. Restart pulseaudio on the Server
  3. Click play to stream the music again

Are there any user with an likewise setup? Is this a bug of mopidy?

2

Haven’t heard any similar reports, but I also haven’t heard of any similar setups.

So don’t if this is a pulse, gstreamer or mopidy issue to be honest.

3

I’ve experimented with pulse network sinks in many forms over the last few years and eventually I gave up because they’re so frequently broken and unreliable. I’ve seen this exact behaviour even without mopidy running so I’m sure it’s not a mopidy problem.

I managed a workaround by using the various pulseaudio GUI tools to enable and disable the outputs every time this happens but I never found a way to do it automatically.

I did manage once to get all this working using JACK and NetJACK instead of pulseaudio, but that was a real trial and I wouldn’t recommend it.