@support
Hi,
Had very bad and time wasting experience over weekend which nothing works.
Here are the details:
My current setup is simple. 1 RPI3 & Odroid C1+ with Volumio streaming DSD to my Devialet via USB.
My friend recommends me Roon to try out.
After reading and understanding it, I decided to run ROON core on my Synology DS1515+ (latest version downloaded last saturday - released version) and use additional MicroSD card to install ROONBridge on RPI3 attached via USB to my Devialet.
Rooncore sees all my music files (Local volume, not share) on my Synology and sees the RoonBridge with Devialet at the USB.
Therefore Synology streams to ROON Bridge which sends the file to USB accordingly and playback happens.
However, no matter how, it just refuses to play the music I selected it pointing to Devialet.
Normal CD quality FLAC (44khz 16bit)
Tidal stream
Hi Res FLAC (up to 24 bit 192khz)
DSD both 1x and 2x running DoP
Errors seen on my iOS remote is : Roon : An audio file is loading slowly. This may indicate a performance or hardware problem.
Therefore I rebuilt by Odroid C1+ with minimal Ubuntu (more powerful than RPI3) and does the same again. Same results.
FYI, RPI 3 I use Ubuntu Mate with Graphical interface disabled.
All network are WIRED.
Tidal is premium account and I am in Singapore.
Link from ROONBridge to my Devialet is via USB. It decodes FLAC/WAV/MP3 and DoP for DSD streams.
All devices along the chain had 0%-2% CPU usage. Even during request for playback.
This is not a new setup. As said, I had this from Volume and it worked the 1st time.
Rgds
Mathew
did you turn off background analyse of tracks (settings | setup) as this will slow the core down and on a rather weak platform like the sinology this might be an issue.
how big is your library? perhaps try the core on a more capable desktop for the trial…and then pass some comments
Yes I did turn off.
Initially I had over 35k tracks. Than I decided to remove it and start of will less than 2k.
I seriously doubt that it is synology load issue as my CPU monitor without the analysis is almost always at 0%. Memory is 10%.
After I issued the command to playback, it stays mostly flat.
As I was using Volumio for all my streaming playback, even loading all 35k tracks and playback DSD, I had no issue.
That is on a tiny RPI3.
Rgds
Audio file is loading slowly is a performance issue likely to be the core or the library source - as both are on the same NAS I would try the core at least on a better platform.
PM me and maybe can compare notes…I have a DS1813+ and 713+ but have had similar issues running the core on the 713+ - not yet tried the 1813+ for the record I deemed both platforms to be way under spec for the core to perform
Hey Matthew – sorry for the frustration here. Thanks for your patience.
The Atom processor in the DS1515+ is slower than we’d normally recommend, but the failure you’re describing doesn’t sound like a normal performance issue to me.
I do understand the load issues well.
In fact I had a friend with same setup but without this issue at all,
If its performance issue, it is quite obvious on the linux platform…etc.
But none so I see.
Hi Mathew,
how did you add your music folder in the storage settings (could you provide a screenshot of it)?
This could also be a network related issue:
A popular misconfiguration is having Jumbo frames activated. If they are enabled on your devices, please turn them off on all involved devices.
Are there any firewalls active?
@crieke
I use “Add Folder” and internal folder structure, rather than add through SMB shares.
Yes, jumbo frames are enabled as I deal with large images. Not an issue I think, as I do not think ROONBridge received anything after handshakes between Core and Bridge. It will skip to the next song, and the next, without “playing them”
There are no firewalls in between them as they are internal networks. All in the same subnet (even I have 2)
Ping routes and such are ok.
As said, ROONCore, ROONBridge and iOS remote sees each other. They speak to each other. They can be configured. However, they just refuses to play.
One more thing. I have disabled and uninstalled everything since I tried 2 days and nights with 2 bridges and walking through the logs. Therefore I could not grab any screen shots any more.
I am waiting for the sales side to extend my trial again. Once it is done, I will redo it to test it out.
Is it possible to test it without having the jumbo frames enabled when you are home again? The symptoms you describe match very much with the experience of other users that had Jumbo frames enabled.
I have to deal with large files (~20GB per file) as well and have tested them in my setup. I deactivated them again as it decreased my network performance. In regular networks they might cause more trouble than the benefit of a slightly faster network performance.
Performance problems arise when the MTU of one device is different from the MTU of another. Making casual changes to MTU to optimize performance is likely to have the opposite effect of decreasing performance.
If most of your local network devices and applications can be configured for the same jumbo frame size, your network might benefit from larger packets, less fragmentation, and less overhead. In modern equipment, this optimization is becoming less of a problem due to LSO/LRO and TCP offload engines, especially on higher end server grade NICs.
All equipment on the same layer 2 network, which means the same LAN or VLAN, should support the same frame size. By default, this is 1500 bytes. If you increase the MTU on one of your end devices, your switch needs to be able to pass these larger frames (same frame size or larger, than default MTU), and the receiving end needs to handle these larger frames as well. If this change is not coordinated, your network might actually run slower, or break.
When should jumbo frames be used?
Use jumbo frames only when you have a dedicated network or VLAN, and you can configure an MTU of 9000 on all equipment, to increase performance. A good example of this approach is a separate SAN or storage network. In all other situations, the effort of configuring jumbo frames everywhere on your network is not worth the marginal improvement, and has the potential of slowing down or breaking non-jumbo frame clients.
Unsure if this is your situation, but jumbo frames don’t really work unless everyone on the network has jumbo frames enabled. This includes WiFi if your switch/router is acting as simple bridge.
Hi,
After disabling Jumbo Frames, things seems to flow ok.
Only occasional disconnect from RoonBridge.
Eg, Roon cannot see the USB DAC I had connected to RoonBridge. A quick hard reset of RPI works.
Now testing different resolution of music.
I realize, only for music in Flac, you can limit the bit rates. However, not for DSD. Which is understandable.
I do hope to limit currently to DSD64, as my DAC is not yet able to decode anything above that.
Rgds
Again, its hardwired on the path of music. No Wireless were turned on along the way.
I see dramatic improvement on my photo editing on the network with Jumbo Frame turned on.
However it is highly possible that RPI do not have JF capability to begin with.
That I cannot confirm.
Hi Mathew,
I am not sure if this might work in your setup: Would it be possible to assign a separate ethernet port for jumbo frames on your synology with its own static IP address that you could connect directly to your computer when editing photos (also with a static IP address)?
I was thinking something very similar. I’ve had very good experiences using the apple thunderbolt gigabit Ethernet adapter in a situation where there was a need for high throughput to the server. The onboard interface went to the normal network for “everything else” but storage was mounted via a separate private network.
If your switch supports bonded interfaces you could also turn of jumbo frames and then bond together two interfaces on the Synology as well as two on the computer for 2x the throughput.
