Volumio3 Multiroom audio not working

I have been scratching my head trying to make Multiroom audio work.


  • 2x x86 HP desktops with Volumio 3.569
  • Both using analog out from the mobo
  • Both have ethernet and are running 1Gbps
  • IGMP Snooping is off on the switch
  • Multicast works for other things on the same switch (VoIP Paging).

I have tried the Spotify plugin both from the web interface and from “casting” from my phone, youtube music, web radio, and airplay.

The audio works from the main device that the grouping is done on, but audio never comes out of the second “grouped” device. Audio was confirmed working from the second device as a standalone player.

Logs show errors related to this:

snapclient[3120]: Exception in Controller::worker(): connect: Connection refused
snapclient[3120]: Error in socket shutdown: Transport endpoint is not connected

UPDATE: This is definitely a bug.

When running: ps aux | grep snapclient on both the server and client machines the same value was returned:

bash-5.0# ps aux | grep snapclient
_snapcl+ 4664 0.5 0.0 253336 9200 ? Ssl 16:39 0:07 /usr/bin/snapclient -d --user _snapclient:audio -s volumioMultiRoomClient -h

This works well on the device the audio stream was coming from as that was also running snapserver and receiving the stream from itself. But this explains why I had no audio on the client device.

bash-5.0# ps aux | grep snapserver
_snapse+ 4677 0.6 0.0 529292 5796 ? Ssl 16:39 0:09 /usr/bin/snapserver -d --user _snapserver:_snapserver -s pipe:///tmp/multiroom/server/fifo?name=Radio&sampleformat=48000:16:2&codec=flac --streamBuffer 50 -b 1500

I was able to fix for now with a temporary workaround while still having the grouping from the web GUI work.

  1. nano /lib/systemd/system/volumioSnapclient.service
  2. Change :
  3. systemctl daemon-reload
  4. cp /tmp/multiroom/client/snapclient.conf /volumio/snapclient.conf
  5. nano /volumio/snapclient.conf
  6. Change:
    SNAPCLIENT_OPTS="-s volumioMultiRoomClient -h"
    SNAPCLIENT_OPTS="-s volumioMultiRoomClient"
  7. systemctl restart volumioSnapclient

Now I need to figure out what part of Volumio creates the file under /tmp/multiroom/client/snapclient.conf, and why it is adding -h even though it is not the server.

Multi room hasn’t worked for me for several weeks either. Not sure what’s going on but it’s infurating.


@Jigitz try my fix above and let me know if it works for you too.

I opened a ticket with support, but will also try to submit a bug report.

Hopefully they can fix this in Volumio3.

Maybe it doesn’t work for you but, but as lot of users I use it every days and it works as this.
Every devices (even the server) is considered as a client to play.
Everything is resampled to 48kHz.
But you’re right to open a ticket!

x86 definitely is broken. Not sure what other users are utilizing, maybe RPI.

Yes it makes sense on the server as it is receiving from itself, but on the client the option “-h” was also being used. This would never work.

1 Like

This is core Volumio functionality, not really x86- or rpi-specific.
Therefore there is no reason why this would be broken on x86.
Tested it just before, works fine.
Tested with a Dell Wyse 3040 and an HP EliteDesk Mini.

Edit: tested with webradio

You are much luckier than me then!

My second Volumio3 device was installed last week, used the latest x86 image, and out of the box ran with the wrong commands for snapclient.

Output of the snapclient config generated by Volumio grouping under /tmp still shows the bug:

Installed Volumio 3.569 on a RPI today, same issue.

At this point Volumio support has been notified and they are working on this.

my working test Volumio 3.569
Integro as Master

volumio@integro-office:~$ ps aux | grep snapclient
_snapcl+ 17207  1.7  0.2  35720  5104 ?        Ssl  18:28   0:04 /usr/bin/snapclient -d --user _snapclient:audio -s volumioMultiRoomClient -h
volumio  17839  0.0  0.0   4156   560 pts/0    S+   18:32   0:00 grep snapclient

Rpi4 as slave

volumio@volumio-rpi4:~$ ps aux | grep snapclient
_snapcl+  2444  3.0  0.4  53220  9348 ?        Ssl  18:28   0:07 /usr/bin/snapclient -d --user _snapclient:audio -s volumioMultiRoomClient -h
volumio   2674  0.0  0.0   4696   524 pts/0    S+   18:32   0:00 grep snapclient

dell x86 as slave

volumio@volumio-dell-salon:~$ ps aux | grep snapclient
_snapcl+ 10985  0.5  0.4 179532  8720 ?        Ssl  18:36   0:00 /usr/bin/snapclient -d --user _snapclient:audio -s volumioMultiRoomClient -h
volumio  11359  0.0  0.0   6180  1792 pts/0    S+   18:39   0:00 grep snapclient

primo as slave

volumio@volumio-primo:~$ ps aux | grep snapclient
_snapcl+  4893  1.0  0.2  39944  6148 ?        Ssl  18:46   0:00 /usr/bin/snapclient -d --user _snapclient:audio -s volumioMultiRoomClient -h
volumio   5058  0.0  0.0   4168   548 pts/0    S+   18:47   0:00 grep snapclient

so, it works as this in my case…
What happens in your case?

@balbuze Mine are below.

How long have you had multiroom enabled? I noticed in the logs when enabling it, it downloads the multiroom plugin since it is a paid feature. Maybe the newest version has the bug?

Alternatively maybe my master has an issue and is not properly relaying its IP address or is relaying “” instead of the proper IP address. After seeing your configs are all using your masters IP address I am believing this could be the case. Luckily for my fix mDNS in snacpacast is working correctly and finds my master whithout an IP specified.

x86 Master:

x86 Client ( I turned this off to start using the RPI client):
grep snapclient
_snapcl+ 4664 0.5 0.0 253336 9200 ? Ssl 16:39 0:07 /usr/bin/snapclient -d --user _snapclient:audio -s volumioMultiRoomClient -h

RPI client:

How do you use multi room?
You just select slave from the master device, right? You have nothing to do on slaves devices.
Is it your case?

Hi, Same issue here - I couldn’t get any multiroom working, this is on a ‘master’ (x86) connecting to 1 slave (x86) and one slave (rPi).

Same issue in logs - error connecting to socket. Bizarrely reboots didn’t help - the only thing got it going was to change the IP address of the master (previously it was dynamic, but stickied to an address), so I set it manually to another and then multiroom worked again - for one session. After this, it returned the same error as above.

Didn’t matter what I did with the source, I used everything from NAS connected files to web radio - the source was irrelevant, it was the multiroom issue that caused the drama.

yes correct!

hmm I tried setting to a static IP address on both master and slave after it didn’t work with DHCP. Still was trying on on the client.

Thanks guys for notifying, we are checking as we speak.

@DED Let’s sync about it

1 Like

Can you guys paste the input of

ifconfig -a

on the clients?


Here you go!


excuse me if i am wrong, but changing an IP address and having 1 good go - for me this sounds like some DNS or mDNS issue.


1.) are you able to ping each device from each device by its network name ?

For DNS one could try and see what happens/helps if the master and the clients are resolved in the local host files of each participiant of the multiroom setup for a first test.

If it has to be mDNS - i am not really good in trouble shooting on that currently - did not have any issues with that.

@volumio @DED Do you use the standard snapcast network ports for multiroom, ? (Sorry - just beeing too lazy to check for… but i guess you will know without having to check on that :wink:

This way one could create a test script - checking all the network ports for availability , give a true / false output condition - in 1 toast message if there are issues - depending on a true - only showing up the “multiroom participiant device at all” in the GUI part…


p.s. - for me it is working - only don’t know why

2 questions:

  • Did you guys use some kind of plugin to restore configurations?
  • Did you clone your SD Cards or flash from new?

We’re debugging this issue which is particularly strange…