Is the affected network Zone connected with Ethernet or WiFi?
· Ethernet
Does the issue affect all file formats?
· The issue *only affects one file *format.
Which format is giving you trouble?
· FLAC
Is your device connected directly to the Roon Server via cable or over the network, or is it chained through another device (such as a streamer, Roon Bridge, or Roon Remote)?
· It is connected through a different device (e.g Rasberry Pi)
Does the device play audio from another source when using the same connection?
· The device has no problems with another audio source
Have you checked that Roon is whitelisted in any firewalls?
· I've checked the firewall and the issue remains
If the device has multiple output options, do the other options work as expected?
· Only one output type is affected while the other output type works as expected
Is the device using the latest firmware as per the manufacturer?
· Firmware is up-to-date but the issue remains
Do you have an approximate timestamp of when the issue last occurred?
· Last night bet 5-6pm est. i was testing with Rosanna by Toto
What are the make and model of the affected audio device(s) and the connection type?
· All listed in details
Describe the issue
Setup: Internet router —>english electric 8network switch —> roon nucleus —>english electric 8network switch—> Hifi Rose 150b DAC: there are intermittent drops and skips with the error “Tidal is loading slowly…”. This has happened with multiple different switches and cable. Seems to happen mostly on lossless flac 96+ files. While setup: Internet router —>english electric 8network switch —> roon nucleus —>USB—> Hifi Rose 150b DAC: this setup has no issues with drop. Its obviously the network piece between the roon and the DAC thats causing it. Is there a way to hard code the ports to full duplex? Or adjust the audio streaming settings? This issue has been lingering for a year and i just added the upgraded switch yesterday and its gotten even worse.
Describe your network setup
Internet router —>english electric 8network switch —> roon nucleus —>english electric 8network switch—> Hifi Rose 150b DAC
We’ve pulled diagnostics from the affected Nucleus to inspect network traces. Here’s what we can see:
Upstream of RoonServer, downloads from Tidal are timing out. Packets arrive late or in the wrong order from the router, stressing the buffer. This occurs with all file types, but Roon recovers with smaller files - the larger 96Khz FLAC files are generally sufficient for the packet timeouts to overwhelm the buffer.
Downstream of RoonServer, the Nucleus is having a hard time distributing samples to the HiFi Rose. The endpoint re-requests samples that it didn’t properly receive - these dropouts accumulate sufficiently to overwhelm playback. Once again, this connection can usually recover with playback of smaller files, whereas 96Khz files tend to expose the sample loss.
You mentioned the issue got worse after installing a second managed switch. The most likely culprits are the managed switches, which might be holding up packets to optimize network pathways. These granular settings often interview with Roon’s uncompressed protocols by scrambling the order in which packets are received, relative to the order expected by the network terminals in both RoonServer and RAAT.
Try bypassing both switches and hardwiring the Nucleus directly to the router via etherent. Hardwire the Rose directly to the same router. Can you reproduce the dropouts with this direct, basic network pathway? Play 96Khz files from Tidal. We’ll pull diagnostics for this test to observe.
Build elements of the network back in, one by one. Try to disable QoS and packet scheduling settings as you add them back in.
Thanks. I have bypassed the switch and have roon and rose connected directly to the internet router’s lan port now. Please pull your diags and let me know when its complete.
Note- I had tried this yesterday (connected both the roon and the rose directly to the available Lan ports on the internet router) and still experienced some drops. I am curious to see the difference on your end.
This never occurs when using USB to connect the Roon to the Rose.
I ran some ping tests as well and saw a few drops from the Rose:
I played for a bit using the verizon router as the switch and the results were ok for that period.
More interestingly I am testing again using my switch - but I am streaming the music directly from Tidal running on the Rose, i have the roon unplugged. I am not seeing the same drops in this scenario either.
If this is the case - and the Roon is struggling with the Tidal stream is there a configuration I can try on the Roon to optimize this?
I want to use the Roon as my digital front end, but I need it to be able to support my english electric switch, because using the Verizon fios router as my switch does not provide the same quality as the EE 8network switch. (And I know that switch should perform fine in this setup).
Did you see the same type of errors when I had the Roon and the Rose both running off the verizon router? I didnt notice any drops. (The other variable is that from time to time things just work, so theres also that lol)
Thanks for the follow-up! It’s good to know things were smooth when you bypassed your switch.
When streaming from TIDAL directly, the audio signal travels from TIDAL’s servers to your device without additional processing. However, Roon integrates TIDAL into its ecosystem, adding DSP options, multi-room playback, and metadata enhancements. Roon’s TIDAL playback also relies on its RAAT protocol, which demands a stable network connection.
Managed switches can cause issues if they block or filter RAAT traffic, especially with VLANs, IGMP snooping, or QoS settings. Ensuring proper configuration—such as disabling unnecessary features—can help resolve connectivity problems.
A few additional things you can test out:
Check IGMP Snooping & QoS Settings – Disable IGMP snooping and any Quality of Service (QoS) prioritization, as these can interfere with Roon’s RAAT protocol.
Enable Flow Control – Some managed switches work better with flow control enabled.
Test with a Different Ethernet Cable – A faulty cable can cause dropouts.
Use a Static IP – Assigning static IPs can help prevent network instability.
I have tried every combination of streaming. Using 2 different switches, and using my internet router as a switch.
I am sometimes able to get things stabilized. For example on Tuesday afternoon I had both Roon and Rose connected to the LAN ports on my Verizon wireless extender /router. (Bypassing a switch). The music was streaming fine through yesterday.
Last night the Roon and rose devices lost power and shut down. When I brought them back up today, I’ve had drops with every setup I’ve tried. I’ve restarted every device in the chain to no effect.
When it gets to this point my only option is to connect the Roon to the Rose via a USB cable. For whatever reason, that ALWAYS works perfectly.
Whatever the issue is between the Roon and the Rose when using ethernet - I need to figure it out. I cant imagine I’m the only one having these issues.
(I’m working with Rose and English Electric as well - but still no answers)
If you experience power outages, we suggest considering adding an ISP to your setup to protect your devices from future damage and potential database corruption.
In addition to this, we see frequent dropouts leading to failure in playback, as well as a buffer overrun on the Hifi Rose - for example:
Trace: [Broker:Transport] [Rose DAC] [Lossless, 16/44 TIDAL FLAC => 16/44] [100% buf] [PLAYING @ 0:19/5:48] Give Up The Funk (Tear The Roof Off The Sucker) - Parliament
Debug: [RaatSender] [raat/tcpaudiosource] disconnecting
Warn: [.NET ThreadPool Worker] [raat/tcpaudiosource] disconnecting + retrying
Error: [RaatSender] while sending frames for Rose RS150: serverside buffer overrun
Warn: [RaatSender] [zoneplayer/raat] Error during streaming: System.Exception: serverside buffer overrun
Warn: [Broker:Transport] [zone Rose DAC] Track Stopped Due to Error
This error means that while Roon was trying to send audio frames to the DAC (in this case, the Rose RS150), the internal buffer on the server side became overloaded – essentially, it was asked to send more data than it could temporarily hold. This “server side buffer overrun” occurs when the amount of data queued for transmission exceeds the allocated memory for that purpose, leading to a failure in sending the frames. As a result, the stream was interrupted and playback stopped.
Common reasons for such an overrun include a sudden surge in data processing requirements, delays or bottlenecks in the data transmission path (possibly due to network issues or processing delays.)
It’s likely that your network switches are throttling data, which is why you’ve been able to (sometimes) hold stable playback with a direct connection from your primary router. It’s also worth testing:
Temporarily disable any active DSP or upsampling in Roon. This can help determine if the processing demands are overwhelming the system.
Test with Different Content or Sample Rates
Try playing a different track or lowering the sample rate to see if the issue persists. This can help isolate whether the problem is track-specific or a broader configuration issue.
Reinstall the firmware to the Hifi Rose and firmware on your network switches
I ran a factory reset on the Rose while it was connected to the TP link switch.
I played 5 or 6 songs with no drops. Figured maybe this jarred something loose.
I then swapped the TP link for the English Electric switch. The drops started on the first song. But my suspicion wasnt the EE, it was still the Rose and how its NIC was set.
So I left the Rose plugged into the EE switch and ran another factory reset. So far i’ve had the same results as the last reset. The music has been streaming without any drops (about 8 songs so far).
So we know a factory reset has an immediate effect. Not sure if it will be a lasting effect tho. My guess is if i make any changes the Rose will tip over again.
(One piece of feedback - Roon should give a better error message when its seeing issues on the server side. “Tidal is loading slowly…” is not only generic but it can send someone down the completely wrong path. Tidal isnt loading slowly, the DAC is loading slowly lol)
I’m curious what your seeing in the logs over the last 30 minutes. Maybe 2:30-3pm est.
Thank you for your diligent testing and thorough response. Here’s what we can observe during the logged period you’ve indicated.
There are some timeouts with Tidal’s API requests but they’re not terminal to the audio stream. Tidal is not loading slowly - you’re correct that the error displayed in the UI is a red herring in this case. Here’s why it’s interpretated that way by RoonServer:
Whenever the EE switch is in the path, based on timestamps and your description of the testing chronology above, the Rose begins to lose samples after precisely half the expected number are received in any given interval of time. So, at 44.1KHz, samples above 22050 begin to go missing and are not reported as received by the Rose. Sequential samples are dropped en route between the server and the Rose - after RAATServer and the Rose identify a certain threshold has been reached, they tear down the audio stream. Since RAATServer interprets that it cannot feed the buffer to the Rose fast enough, Roon displays an error the media is loading slowly. It’s not really that accurate here.
There are two likely causes to the issue. It’s certainly possible that a firmware glitch in the Rose, temporarily relieved by firmware reset, causes the buffer to close earlier than expected for the file size. Another plausible solution is that active packet scheduling, flow control, or QoS features in the EE switch are attempting to hyperoptimize packet routing to the endpoint, but accidentally interfering with the order of packets as expected to be received. The SPT implementation of the switch is a factor as well.
We’ve inspected Roon Ready logs reported to RoonServer by the Rose. We don’t see any errors in its capability reporting or the handshake with Roon. It tears down as expected when the network begins to drop samples. We don’t have conclusive evidence that there’s an issue with this device, but you would likely need more granular logging to know for sure by contacting Hifi Rose support.
Since you haven’t reproduced the dropouts with the EE switch bypassed, the evidence from testing favors that the switch’s managed network settings are the cause. The symptoms might not always be present when the switch is in use - you can try different ports, or enabling/disabling any settings related to packet scheduling or bandwidth allocation/QoS, etc.
I recommend trying with the switch bypassed and playing a lengthy session of high-resolution (192Khz) tracks to the Rose. See if you can reproduce these errors with the switch fully bypassed - that’s the most precise way to test the Rose for a firmware issue.
I did a firmware reset of the rose at about 2pm est. i had it connrcted to the EE switch when i did. I have been playing only hi res
music on and off from 2pm est until now (5:15pm est) and have not had any drops.
To clarify - with or without the EE the rose was dropping. At one point the Rose was connected directly to my internet router and i was streaming Tidal from the Rose built in dac (Roon completely disconnected). I STILL had drops.
Like i said, the only constants were the following:
No matter what setup I use, if I set the Rose to use a USB input, and run a USB cable between my Roon and my Rose, there’s NEVER an issue.
No matter what setup I use, if I set the Rose to use ethernet input, theres ALWAYS an issue.
Since the factory reset a few hours ago, with the EE in place, i am not getting drops.
Rose is pointing at a network issue (altho they havent done any troubleshooting and I have spent hours testing)
Any network device or streaming server i use with the Rose causes drops when the issue is occurring. In every scenario… except when i disable the Rose ethernet port and receive over USB.
I’m annoyed Rose would point to a network issue without performing troubleshooting. I would appreciate data points from you guys showing that the issue is isolated to the Rose
So that I cam send it to them.
We can certainly help, I do want to point out that you yourself already have a strong datapoint off of what you’ve already mentioned:
In addition to this, we can see from a recent diagnostic report that continued dropouts over the Rose when connected vid the network eventually leads to stoppage in playback:
Trace: [.NET ThreadPool Worker] [Rose RS150 @ 192.168.1.173:42341] [raatclient] GOT [17] {"samples":96000,"status":"Dropout"}
Trace: [.NET ThreadPool Worker] [Rose RS150 @ 192.168.1.173:42341] [raatclient] GOT [17] {"samples":96000,"status":"Dropout"}
Trace: [.NET ThreadPool Worker] [Rose RS150 @ 192.168.1.173:42341] [raatclient] GOT [17] {"samples":96000,"status":"Dropout"}
Trace: [.NET ThreadPool Worker] [Rose RS150 @ 192.168.1.173:42341] [raatclient] GOT [17] {"samples":96000,"status":"Dropout"}
Warn: [Worker (4)] [Rose DAC] [zoneplayer/raat] Too many dropouts (>3s dropped out in the last 30s). Killing stream
Trace: [Worker (4)] [Rose DAC] [zoneplayer/raat] too many dropouts. stopping stream
Warn: [Broker:Transport] [zone Rose DAC] Track Stopped Due to Slow Media
We also see repeated failures in connection with the Rose:
Hey team- my dealer loaned me a Rose 250 to test out in place of my Rose 150. I have been streaming with the 250 since about 2pm EST. I havent experienced any drops yet.
Could you please take a look at the Roon logs to see if there’s a more stable network connection with the new DAC in place?
If you haven’t experienced any dropouts, that in itself points to a more stable network overall. Based on another diagnostic report, we still only see dropouts in relation to the 150.
Hi @neillucey19,
Great to hear you tracked down the source of the dropouts! I’ll go ahead and mark this case as solved, but it will stay open for a couple more days just in case anything else comes up. Feel free to reach out if you need any further help!
)