Does the issue happen with local library music, streaming service music, or both?
· *Only streaming* music is affected.
Please select the streaming service(s) with which you're encountering playback problems.
· TIDAL, Qobuz
Have you tried logging out and back in again to your streaming service in Roon Settings?
· Logging out and back in had no impact, the issue remains
What are the make and model of the affected audio device(s) and the connection type?
· Not likely a device as is seen on PreSonus interface connected to Mac Studio, Apple AirPort Express, and RPis running Ropieee
Describe the issue
After updating to Roon 2.0 build 1490 on server/remote (Mac Studio w/ macOS 15.2) playback through all devices and on the Mac Studio randomly stops after some time between a few to 40 minutes.
Describe your network setup
Internet connection to Mac Studio is via Ethernet, and connections to end points are all wired Ethernet
As a first step, can you double check your Mac firewall settings to ensure Roon is listed as a proper exception? An easy test for this can be to temporarily disable your Mac firewall and see if the same issue occurs. Here’s more info:
Can you confirm that all your Roon devices stay on the same local subetnet within your network, especially during playback? Please disable other subnets temporarily to ensure all devices are functioning within the same subnet and let me know how things perform.
If you’re still running into issues after the above, we have seen users have a better experience in the past if they change their Router’s DNS servers from the ISP provided ones to Cloudflare DNS, Quad9 or Google DNS. Can you please give this a try and let me know if it helps?
Benjamin I saw this post as a response to another problem report and tried all but the DNS server and still had the random playback stop issue, before I filed my report. I also neglected to mention that several times after starting Roon there was a “RAATserver” failure popup with a lot of code, occurring several times. I rebooted the Mac Studio several times, after closing ROON, and haven’t seen the RAATserver issue in a day or so.
I’m pretty sure this is a result of either the last ROON SW update loaded yesterday or the macOS update also loaded yesterday. Unfortunately I didn’t run ROON after just doing one update too long.
I’ll try the DNS thing for grins. Also note sometimes the random stop takes as long as 40 minutes to occur so it’s hard to know for sure if the problem exists.
Hi @likeanice1903,
We’ll be on the look out for the results of trying the DNS. If the issue with playback happens again please note the date and time it occurs and let us know.
DNS changed to Cloudfare and album played that stopped playback after ~35 minutes. Time approximately 9:10 PM EST on 19 Dec. Previous stops were noted while playing playlists of selections from various albums. No further “RAATserver” exceptions.
Roon continues to stop playback randomly. In addition to other examples given previously, this also happens while listening to a radio streams and music in my library sourced from the local drive. In all cases the Roon transport || (pause) symbol reverts to > (play), same as if playback is stopped by mouse-clicking the || (Pause) icon. This is a fundamental flaw that I have to believe is in the release and needs to be corrected. Let me know if I am wrong and I am the only customer with the problem and if so, next steps.
Daniel where are you guys on this issue? This is extremely annoying. I’ve been a subscriber for at least 2-3 years and this is a fundamental problem that simply should not be happening at this point in Roon’s company history. If Roon cannot reliably playback anything from any source, what good is it?
Thanks for your patience so far, and you have my apologies for the delay!
Based on a recent diagnostic report from your Roon Server, we saw repeated indications that playback failures were caused by repeated audio dropouts, and samples are not being delivered to the DACs in time for continuous playback.
When these dropouts occurred, we saw the track buffer was only at 3%, which suggests insufficient buffering to handle audio stream interruptions. In addition, the issue occurred across multiple endpoints (Ropieee LR, EDM Studio, and RoPieee Den), suggesting a systemic issue rather than one limited to a specific device.
What happens if you increase the buffer size within the zone settings in Roon?
Do you have any additional network components that may be throttling bandwidth to your Mac studio running Roon Server? If you can simplify your network and overall setup, temporarily, this would be a helpful test.
Benjamin I appreciate that you can do some remote debugging. There is no “buffer size” parameter for any of my devices. Furthermore:
The Roon endpoint devices and network have been stable for a long time and the problem did not occur until the Mac Studio running Roon Server was updated to macOS 15.2 and/or the latest Roon SW update. Let me describe each:
a. “EDM Studio” is a PreSonus “STUDIO 26c” connected directly to a Mac Studio USB C/Thunderbolt port. I am pretty sure it has had random playback stops as the only endpoint playing (i.e. when not in a group). b. Ropieee LR and RoPieee Den are Raspberry Pis running latest RoPieee SW, both Ethernet connected to the LAN. c. Redbook_Den and Redbook_LR are both Apple AirPort Express modules, also Ethernet connected.
The Network routers are supported ASUS units less than 1 year old, the Mac Studio is also less than 1 year old.
When Roon is being used there are never any other devices on the LAN that are doing bandwidth intensive chores. In fact, the IPTV signal is separately fed from the Lumos fiber interface modem.
I could simplify the network somehow I suppose, however, having the PreSonus audio interface directly connected to the Mac Studio is as simple as it can get I assume.
The WAN is Lumos 1 GB fiber, both directions.
Are there any macOS settings that may have come to play in macOS 15.2 that could cause this?
I appreciate the troubleshooting and am surprised this apparently not a more universal problem. Please let me know next steps.
We’ve seen reports of local audio devices losing connection with Roon specifically (from the audio settings page) but not so much around audio drop outs, or at least not specifically related to the recent Sequoia update.
On that wavelength though, do you have your Mac firewall active on the server machine? What happens if you temporarily disable it - can you reproduce the issue?
And if possible, are you able to test playback from the system output of the Mac studio?
We reviewed a fresh diagnostic from your Roon Server, and didn’t see any obvious errors during playback, how have the last 24 hours been?
Thanks for the update Benjamin. Regarding your questions:
I have not used Roon much in the past 24 hours so I am not surprised that no errors were seen. Note that it can be a long amount of time between playback stops (hours mostly, but can be as short as minutes).
The Roon “Audio” settings page allows two system outputs- one plays to the Apple Display connected via Thunderbolt cable, the other is the really bad speaks in the Studio box itself. I will play a radio stream through the Studio box when I am not home and see if it happens.
In the Mac Steetings > Network > Firewall, the Firewall is active. However under Settings > Network >Firewall > Options, the “Block all incoming connections” switch is OFF, and the following Roon-related items in the list show as “Allow incoming connections” a. “RAATServer” b. “Roon” c. “RoonAppliance” d. “Tailscale” (note that I have had Tailscale active on the Mac Studio and my iPhone and last time I checked Roon ARC was working. To that point, in Mac Settings > Network > VPN also shows that Tailscale is active). Before I turn off the firewall for what could be hours long testing, can you let me know if this still makes sense since Roon-related incoming connections are allowed. Also, are there any other Roon elements that should be enabled in the list?
I recall some Roon releases back there was a problem with Apple AirPort Express modules dropping from the Audio (settings) list. That was subsequently fixed and is not an issue- all my devices are stable on that page.
Just to review exactly what happens with the Roon transport controls: At the bottom of the screen is “Previous” (with the lamp to its left indicating “Signal Path” when playing), Play/Pause, and “Next” (with the Queue button to it’s right). When this error occurs the play symbol goes to “Pause.” To restart playback, one has to click the “Pause” symbol. I don’t recall if the signal path lamp goes off but will note that in the future. So it’s not a dropout problem per se. I think I have witnessed a very few actual dropouts where playback is lost briefly, seemingly moreso with Qobuz vs. Tidal. Presumably that could be on the streaming serve end…
We’ve examined diagnostics more closely from the affected RoonServer and RAATServer instances.
Sample dropouts are accumulating as RoonServer buffers the audio stream - eventually, they accumulate in sufficient numbers to overwhelm the buffer, and you experience an automatic pause or audible interruption to playback. This occurs with every Zone, but it occurs more frequently with grouped Zones and with higher sample rates/bit depths.
Taken together, these symptoms indicate that the network path between RoonServer and the internet - and between RoonServer and your Ropiees - is experiencing either interference or issues with packet routing/managed network software.
You’ve mentioned that this Mac is connected via ethernet - have you disabled the WiFi connection, to verify that RoonServer isn’t intermittently relying on that network interface?
What hardware sits in between the Mac RoonServer and the internet? Make sure multicast forwarding and IGMP snooping are enabled in any router or firmware, particularly if there is a mesh network involved.
Please try restricting playback to 44.1KHz in your Device Setup for the System Output of the Mac and attempt to reproduce the issue. Gradually increase the sample rate and see when dropouts occur. Please share a timestamp of this event here or the name of the track that was playing when the incident occurred.
How precisely have you configured these Airport Express modules in this topology?
How many routers do you have in this configuration? We need a precise picture of your network topology to assist at this point.
This depends on the network pathway serving the Mac, and how many network interfaces are available on the Mac. I’d also verify that the MacOS itself isn’t restricting RoonServer’s network access by navigating to System Settings → Privacy & Security → Local Network and toggling on network access, if you haven’t already.
Connor the continued support from Roon is much appreciated, and I am impressed with the level of diagnostics capability seen on this problem.
I was surprised to see that WiFi access was enabled on the Mac Studio running Roon server. My guess is that the macOS 15.2 update enabled it. I recall that happening with a macOS release long ago, so I’ve made a mental note to check that with every macOS update in the future. Furthermore, I think this reversion of “WiFi enabled” caused network issues with Roon in the past.
Regarding your last point, I verified Roon has local network access.
At times in the past I have had playback issues with high sample rate material, seemingly due to source/Internet throttling, moreso with Qobuz than Tidal. In those cases, Roon often displays a message when the playback stop occurs.
I also had intermittent playback issues in the past I suspected were a result of Roon endpoints being WiFi-connected, which motivated me to run cable such that nothing “Roon” is WiFi connected.
The (ancient) AirPort Express modules are specifically configured to have their radio off, and are currently only used as Roon endpoints. However, one of them is relaying the Ethernet connection to a Ropiee via its single switch port. The AirPort Express only has a 10/100 interface. Everything else in my network is 10/1000. All cables are CAT-6. While I assume 10 Mbps should be enough for the Ropiee, could I be wrong?
I will check router multicast forwarding and IGMP snooping ASAP, and also generate a detailed block diagram of the network.
My bet is that turning off WiFi on the Mac Studio will fix this issue. Otherwise I will reduce sample rates as you suggested to troubleshoot. I will followup again soon.
Connor the random playback stops where the pause icon reverts to the play icon have not occurred since disabling WiFi on the Mac Studio running Roon Server. However I have still heard audio dropouts every now and then.
In one case, Monday night around 9:22 PM with a single 44.1/16 stream to the AirPort Express connected to the primary router (see block diagram), the dropout was many seconds and I stopped and restarted the (nonexistent) stream with the pause/play icon.
One thing I haven’t noted before, is that in all cases I am using a Wi-Fi connected device to remotely control Roon. See block diagram; primarily the MacBook Air or iPad, sometimes iPhone. The remote display is showing track progress in real time of course. Could this be causing dropouts, e.g. via WiFi dropouts to the remote?
I did install the latest Roon SW update immediately, dropouts occurred after that update. No further macOS updates have been installed.
Note that multicast routing is enabled (see screenshot), and so is IGMP snooping on the router Wireless-Profession page.
Is it possible to tell if Lumos is providing a sub-par fiber link with a high error rate? Is there an independent way to test for this?
Our apologies for the long delay here! Please see notes in-line below.
Fortunately, this is not likely the case. The Roon controllers don’t actually touch the audio stream, and only interact with RoonServer and endpoints for lightweight control.
There are two possibilities here, depending on the source of the track. If the track originated from a streaming service, then the download speed for a 44.1KHz isn’t as important as two other factors:
a) the ability of the assigned DNS server to resolve the Tidal/Qobuz API address
b) the throughput of the network path and whether managed software is holding up packets while optimizing routes
c) the bandwidth allocation to the downstream network components.
You can address these by:
a) verifying Cloudlfare or QuadNine (1.1.1.1 or 9.9.9.9) is assigned for DNS resolution
b) A/B testing without the Airport Express modules in the network path
c) verifying that no Quality of Service of bandwidth throttling is robbing RoonServer.
This feature will switch back and forth between the available WiFi bands to optimize throughput. I recommend disabling this and restricting the network to either the 2.4 or 5.0 band for testing.
Another thought - I recommend updating to Sequoia 15.3, which users have reported broadly to resolve local network disconnection evens with RoonServer. Additionally, in your WiFi → Details settings, try restricting the WiFi Address to a “Fixed,” not a “Rotating” address.
Please note in the block diagram above that no paths for sound data involve WiFi, all are Ethernet connections. Since you stated that the WiFi control data connections should not cause audio dropouts, WiFi is not the issue here. Having said that, please note that the Asus “smart connect” feature is and has been turned off.
I am using Cloudfare DNS, that change was made when you first suggested it, and it’s had no effect on the problem.
I have kept macOS up to date, installing 15.3 as soon as it was available. The result was no change, dropouts still existed. Perhaps they’re even worse. You stated other users had dropout problems with Roon and 15.3. I’m curious about that.
The problem exists no matter the single endpoint- Ethernet-wired AirPort Express or RoPieee; or USB from the Roon server PC to a PreSonus DAC. While I often use multiple endpoints, the problem exists even if a single one is used. The block diagram doesn’t show this, but both RoPieee devices connect via USB to a Benchmark Media DAC. In one case a DAC2, the other DAC3 HGC. The AirPort Express boxes connect to a Tascam CD recorder via their fiber SPDIF interface.
The problem exists independent of source, Tidal, Qobuz or library stored in the Roon server PC storage SSD.
No hardware changes proceeded the problem. The block diagram above has been the same for at least a year.
The problem occurred after the update to macOS 15 SW, simultaneous with a Roon update (now 2 back I think). However, this may not prove anything- perhaps the Lumos service in my area has developed a problem, or some hardware is failing. Still, given the long time of reasonable trouble-free service before those updates, it feels like a SW issue.
Can you guys continue with remote troubleshooting? Last night I was playing a playlist to a single RoPieee endpoint, and several songs in, multiple interruptions occurred in one tune. If I log exact times for these issues, and relay them to you, can you look at it?
Also, it’s interesting other users have had issues with Roon and macOS 15.
I much appreciate your continued attention to this. I have to believe it is more widespread than with just me. For me, this makes the Roon model unusable. I haven’t tried simply using the Qobuz or Tidal App for streaming. Or Apple Airplay for my music library. All terrible compared with the Roon integration.
Thanks for the detailed follow up, sorry to hear your dropouts are still occuring.
From your Roon Server diagnostic report, we’re still seeing hints of the machine hosting multiple IPs, across different local subnets. Were you ever able to disable the other potential subnets and confirm Roon and all your endpoints remain on a single subnet during playback?
