ROCK (RAAT ?) communication with networked end-points ageing/degrading over time?

Roon Core Machine

  • ROCK (fully updated) on Intel NUC10i7fnh

Networking Gear & Setup Details

  • Siligence TCG300 ISP modem/router (ISP)
  • ROCK (fully updated) on Intel NUC10i7fnh, direct CAT5e connection to Siligence TCG300 modem/router (from ISP)
  • RoPieeeXL (fully updated) on Raspberry Pi4 B 4GB, direct CAT7 connection to ISP modem/router (through CAT5e patch cables at both ends)
  • Google ChromeCastAudio devices, establishing wifi connections with ISP provider MeshWiFi Access Points, which are connected through a D-Link DGS-1008D switch to the ISP modem/router

Connected Audio Devices

  • Marantz NA8005 USB-DAC, connected directly to the ROCK NUC
  • RoPieeeXL (fully updated) on Raspberry Pi4 B 4GB + DoukAudio P1 USB-DAC
  • Google ChromeCastAudio devices/group, establishing wifi connections with ISP provider MeshWiFi Access Points
  • SONOS speakers, establishing wifi connections with Ubiquity Mesh Access Points (rarely used)

Number of Tracks in Library

Description of Issue

Almost 4 years ago, I bought a Roon license after a trial period through Qobuz and I installed ROCK on a NUC in my “mancave” where it is connected to an USB-DAC, which forms the primary music listening zone in our home. I created some further zones for end-points which are connected through wifi or wired ethernet in other rooms of the house. The NUC remains switched-on continuously and serves music from Qobuz and local storage (the latter residing initially on a NAS, but later-on (also) on a USB-attached SSD to the NUC).

Aside from some spurious hiccups (initially mainly in the wifi connected zones), the setup performed as expected. But the experience deteriorated over time: sound interruptions, sudden jumps to the next track (even skipping tracks) in the queue, halting of playback queues and also temporal indications of lost connections to the Roon Core in the Roon apps on smartphone and tablet. Reducing the payload on the zone output by minimising the track sampling rates had no effect.

Appreciating the Roon functionality and the professionalism which I read between the lines in the Roon Community entries, I started investigating our network setup and had several discussions with our ISP at the time on the quality of their modem/router and wifi access points which we had in use. I added a wired RoPieee zone (connected to another USB-DAC), but also this one suffered from the same issues, while the direct USB-DAC connection to the NUC remained flawless (both for Qobuz playback and local playback).

We switched ISP last spring, implying a replacement of modem/router and wifi access points in our LAN, but the issues kept aggravating over time. I simplified the LAN topology for testing, exchanged a local switch, studied the configuration settings of the ISP modem with regard to multicast and broadcast network traffic… I increased the load on the NUC by operating 5 configured zones simultaneously, each with DSP upsampling enabled, while copying at the same time a large video file to the NUC SSD (for which Windows indicated a continous data transfer rate of over 100MB/s) : the directly connected USB-DAC to the NUC kept functioning without any issue (even when playing music from the NAS over the fully loaded 1GB/s wired ethernet connection) ; the other zones kept experiencing the same problems mentioned above…

Salient detail : my old pre-Roon DLNA streaming setup (using the standard Twonky Beam server app on a cheap Zyxel NAS, together with the BubbleUpnP app as controller) still performs flawlessly over the same LAN configuration to the same render end-points (all of them : Google ChromeCastAudio instances/groups, RoPieeeXL, Sonos) …

To my feeling, I isolated the problems to a software part within ROCK which is used for networked end-point communication (RAAT ?), but not for directly connected USB-DAC communication. A first reboot of the NUC seemed to improve the situation initially, but it was only a short moment of relief and further reboots did not bring anything anymore …

The only (drastic) attempt to solve the issues which I did not yet perform so far is a ROCK reinstall from scratch on the NUC, which I hope will not be required (risking destruction of my Roon library ?)

CONFIGURATION DETAILS:

  • ROCK (fully updated) on Intel NUC10i7fnh, direct CAT5e connection to Siligence TCG300 ISP modem/router
  • RoPieeeXL (fully updated) on Raspberry Pi4 B 4GB, direct CAT7 connection to ISP modem/router (through CAT5e patch cables at both ends)
  • Google ChromeCastAudio devices, establishing wifi connections with ISP provider MeshWiFi Access Points, which are connected through a D-Link DGS-1008D switch to the ISP modem/router
  • SONOS speakers, establishing wifi connections with Ubiquity Mesh Access Points, which are connected through a TP-Link switch and (another) D-Link DGS-1008D switch to the ISP modem/router. REMARK : network simplification for testing consisted of removing this full set of components. This is end-point is rarely used.
  • all cabling/connectors are at least CAT5e (parts are CAT7)
  • USB-DACs : Marantz NA8005 (primary listening zone) and DoukAudio P1 (connected to Pi4)

Just a fellow user here, and suggesting to look at the indicated processing speeds of the failing zones in the signal path display - let’s see where those numbers are!

1 Like

I won’t be much help here. But one point. My understanding is that Roon/RAAT is decoding any file it plays to full size BEFORE sending it out over the network. This is in contrast to many other server/players that send the file to the player endpoint, and the endpoint/player then decodes. For example, in my setup, Roon decodes my FLAC files and sends a full PCM file to my endpoints for playback. But my LMS setup sends the FLAC file across the network and my endpoint players decode the FLAC file to PCM at the endpoint itself. Consequently, the bandwidth used by Roon is double the bandwidth used in my LMS setup. This could explain why you see issues with Roon as compared with your other streaming method.

Also, be careful with CAT7. If not used properly, CAT7 can create grounding issues given the way they are terminated. One is much better off using Cat5 or Cat6 unless one knows very explicitly how to use CAT7 cables (which is NOT the same as pre-CAT7).

Good luck.

2 Likes

Progress since my initial entry:
This weekend, a major Devil in Disguise unveiled itself in my network, and it was …
not Roon !!
The mentioned problems are not fully gone, but the zone with RoPieeeXL improved a lot, the zone with Sonos didn’t …
So, what was the culprit ?
One of the 2 Chromecast Audio devices is connected via optical cable to a Marantz MCR603 Melody Media. While listening in this zone, I spotted “Signal unlocked” messages appearing on it’s display during audio hiccups. A little bit later, there was no audio anymore, but only regular notification sounds from the Chromecast Audio of wifi-reconnections. A problem with this device (or it’s power supply) ? I removed it from the network and had to reboot the network switches to reobtain a stable configuration.
I guess it might have been disturbing the network unnoticed for already quite some time through it’s wifi connection.

So now, the situation looks better, let’s monitor it for a while … (without the Chromecast zone)

With regard to the CAT7 cable segments, they are not attached to ground at neither side to avoid indeed potential groundloop issues. I considered it also overkill at the time, but it was delivered and installed …

(And the indicated DSP processing speeds are also fine, never below 10)

Thanks for the initial replies !

1 Like

Eventually, the real culprit has been identified : the internal LAN switch of the Siligence TCG300 modem/router from the ISP.
So, it was in the end indeed a LAN problem, not an issue with Roon.
Because the ROCK NUC was directly connected to this (rather recent) device, it served all end-points through the internal switch and they all suffered from it’s bad performance.
Changing the LAN topology by moving the ROCK NUC (and alsof the RoPieee) connections to the D-Link switch instead removed the playback issues on all end points simultaneously.
Fetching the internet Qobuz stream through the modem does not seem to be impacted by this performance issue.

1 Like

This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.