Bluesound Not Working with Roon [resolved]

With excitement I tried to get the new BlueSound O/S integration to work, but no luck. I need help at this point, the manner of this issue is very mysterious.

My Configuration:
Synology 3615 XS+ running Roon Core on SSD – Latest SW
Synology Network Interface: 2 Bonded LAN Ports; 2x1000Mbps; Full Duplex; MTU 4000
3 Bluesound Node2 Endpoints – current SW/FW
1 Apple TV Endpoint
Netgear Nighthawk R8500 Router
Music Library = ~6000 Albums, Redbook FLAC, HiRez FLAC, and DSD

The Symptoms:
Roon sees the Bluesound endpoints and is configured. I can use Roon to play a track on an endpoint and it shows the signal path and the play marker moves forward as if it is playing, however, there is no sound out of the Bluesound (yes, volume is set correctly).

Now, this is where is gets even stranger. I have no problems using Roon to send music to the Apple TV (not RAAT of course), this works well. Also, the Bluesound units work just fine when controlled by Bluesound’s application. Further, when attempting to play to a Bluesound unit from Roon, the Bluesound app shows it is playing from Roon and properly displays the album I’ve selected in Roon – just no sound coming out. I’ve included some screen shots with this posting. This is very frustrating and any help would be greatly appreciated.



That’s an excellent support post, having lots of details, it’s also useful to “call” @support.

A screenshot of the settings cogwheel beside one of the bluesound nodes would possibly be useful.

Could the volume be muted somewhere in the chain?


Thank you. I will add the additional screen shot as you suggest. I am not sure what you mean by “call” @support.

I do not believe there is any mute on in the chain. I did note a post by others indicating they had problems with bonded network links. I have a relatively high-end NAS that uses a bonded network connection for bandwidth. I am wondering if Roon has some issues when it comes to supporting bonded network interfaces - I’m shooting in the dark on this.

One thing that caught my eye: Your MTU is set to 4000. I am unsure if this is an issue here. When you use jumbo packets, all network components should support this as well and I do not know right now if bluesound does support it . But the normal behaviour with incorrect MTU value is, that the playback aborts and Roon will prompt an error (“An audiofile is loading slowly…”).
It is just a guess right now but if it is no big deal, you could try to set it to its default 1500 value (although the symptoms seem different in your case, and I am not convinced this is the issue here…)

Good eye! However, note that Bluesound works just fine with these settings when controlled by Bluesound’s application so I do not believe that the BS devices have any issue with this MTU value.

Network setups are sometimes quite tricky. Errors in the setup do not come to light in every scenario as different protocols might handle network traffic differently. This is also something I learned with jumbo frames… :wink:
But as I said before: Also to me it does not look like the “typical” MTU error…

Fair enough. I share your experience with sometimes tricky network issues. To take it off the table for certain, I will adjust the MTU value later today and give it a try. I am hoping that @support will respond with some thoughts as well.

I had to get on a vm as it seems that docker does not handle broadcast address correctly, are you using docker to run roon core?

Nope, I have a basic install using the install script by Christopher Rieke (@crieke) following the standard published install steps which I do not believe use Docker - Docker is not installed as a package on my NAS.

then indeed the mtu might be part of the culprit probably not fragmented when using broadcasting

If you have mismatched MTU’s on your network and things are working, you are getting lucky. MTU really must be set consistently, everywhere, or left at the default 1500 everywhere. Some apps can tolerate having this detail mis-configured, but others will experience problems.

RAAT is sensitive to mis-configuration of MTU, particularly when you set a higher MTU on your core and do not have set it to the same level on your endpoint hardware. This leads to a situation where the core isn’t aware that it needs to fragment audio packets (because it’s configured for high MTU), and the endpoint ends up dropping them because they’re too large (because it’s configured for a lower MTU).


Thank you @brian and @De_Cock_Xavier, I will try this evening with the default MTU size of 1500 and report back. (As I just received an eMail, perhaps I will be testing this on 1.3!) Thanks.

Thank you everyone for your help, changing the MTU size to the standard 1500 resolved the issue. Thanks again!