Thank you for your patience and our apologies for the delay.
To summarize the issue with reference to the block diagram:
The Raspberry Pi connecting to the second router is encountering sample dropouts and a broken pipe error in the TCP connection that together interrupt playback
The Raspberry Pi connecting to an Airport Express is experiencing sample dropouts
Any endpoints grouped to either of these Zones lose sync due to dropped samples with the Raspberry Pis
Since this is agnostic to source (streaming vs. local), we can assume the blockage is within the LAN.
The broken pipe occurs when the stream has already closed on one when the client connects and expects data.
Let’s try connecting to the Airport Express as an Airplay Zone (add it to the Apple Home app on an iOS device). Turn on Compatibility Mode in the Device Setup page in Roon Settings → Audio. Do you experience dropouts with Airplay when you play to this Zone? This will help us identify if there’s something wrong with the network connection to this node, or with the protocol itself.
ou’ve already tested playback to the RoonServer Mac System Output and the PreSonus and experienced dropouts - can you please repeat that test, but play local files at 44.1KHz to this Zone? Downsample everything as much as possible.
Next, try connecting one of the Raspberry Pis to the Primary Router location as a single networked Zone in Roon. Try to play lower-quality (44.1KHz) tracks to this endpoint - do you experience dropouts there?
We might have misunderstood one another; MacOS 15.3 resolved known issues with 15.0-15.2.
Other users had issues with Apple 15.0-15.2 restricting RAATServer’s access to the loopback. Apple calibrated network security with 15.3.
In this case, there may be a piece of managed network equipment scheduling packets in a way that disagrees with Roon’s uncompressed streaming protocols. We’ll check diagnostics after you’ve performed the tests above, and thank you again for your patience!
Thank you for the update Connor. I will run these tests and follow up. A few other points:
(1) As I play most material from Tidal or Qobuz I am not absolutely positive the issue currently exists (with latest Roon/macOS updates) with media stored locally on the Mac Studio. Most of that material is legacy ALAC 44.1/16, I’ll test more as you suggest.
(2) There was a music stop yesterday at 5:05 PM EST on the AirPort Express connected to the main router ~45 minutes into a 55 minute playlist. A track stored locally on the Mac Studio had played, and then a few minutes into the following track from Tidal the stop occurred. Another 56 minute playlist ran flawlessly right after that. Any way to look at that?
Furthermore, I realized this AirPort Express is connected to the router via a cheap Chinese switch (TrendNet TEG-S5g), not shown on the diagram. I removed it and connected the Express directly to the router. Not sure if this could be an issue…
(3) The ASUS ZenWiFi routers have been in place over a year, pretty sure going in before this problem occurred. They are on auto-update and every time I check, their SW is current. I need a wired access point connected to the main router due to the construction of my old home blocking RF between two sections, so from a features standpoint it fits. Still, if Roon has other router equipment suggestions I’m open to them.
(4) It would be cool if Roon had some way to do bit error rate checking on incoming Tidal and Qobuz streams.
This morning using the AirPort Express connected to the main ASUS router (with the TrendNet switch removed) I played the first track (named “HALO OR THE HORNS”) in a 1 hour playlist, stopped it before its end, and then started the playlist again. Soon after the restart there were a few audio dropouts corresponding with digital stream interruption from the AirPort Express in that track. I restarted the playlist again and it played flawlessly to the end. So perhaps the TrendNet switch wasn’t an issue.
The Tidal track that stopped Monday at 5:05 PM was named “I’ve Got a Feeling” (Lucinda Williams).
I have seen numerous times over the years of Roon releases a dropout/stop soon after starting a playlist, then never to occur again after a restart of the playlist by the way.
As an aside I just put a HifiBerry Digi2 PRO on the system using RoPieee. The idea is to replace the AirPort Express modules. I will try audio through it tomorrow. Do you know if there is a way to constrain the digital output resolution of the Digi2 PRO within Roon? There doesn’t seem to be a setting in the Audio setup for that. Alternately, if the Digi2 PRO is connected to a SPDIF device that only works at one resolution (e.g. 44.1/16), will Roon perform transcoding as required?
Also, I note the RoPieee devices have a “Resync Delay” setting in Roon Setup>Audio. I have it set to 0 ms for all devices. The Benchmark DACs are ok with that, and because the dropout/stop problem doesn’t occur at the beginning of tracks, I am thinking there is no reason to try a non-zero value. Comments on that?
We reviewed a fresh diagnostic report, and saw some interesting traces in relation to Apple’s TimeMachine right around the time you were playing back the track you listed above - here’s an example:
Warn: [.NET ThreadPool Worker] could not run /usr/sbin/diskutil info -plist 'com.apple.TimeMachine.localsnapshots/Backups.backupdb/EDM Mac Studio/2025-03-03-170542/Data' -- Exit code was: 1
Using Time Machine on the same machine as your Roon Server is not recommended because Time Machine’s continuous, disk-intensive backup process can compete with Roon’s need for fast, real-time access to your music library. This contention may cause audio dropouts or glitches during playback. Additionally, the backup process can increase overall system load and interfere with file access, potentially leading to instability in Roon.
If you disable TimeMachine, do you still run into playback issues?
The message “failed to send rtp audio packet: No route to host” means that the network stack couldn’t find a path to deliver the RTP packet to the device.
This failure leads to a “Broken pipe” error in the RTSP connection, meaning the connection between Roon and the AirPlay device was interrupted.
Once the connection was lost, Roon received a disconnect and sent a suspend command, effectively stopping playback.
Are you able to test out setting up a static IP for the Airport device?
(1) Can I assume that if I leave TimeMachine enabled, but set to manual backup, that there will be no conflict with Roon as long as I am not playing anything at the time I trigger a manual backup? (This assumes Roon is still running on “EDM Mac Studio”). Alternately I can exit the Roon application before running a TimeMachine backup.
(2) I set up static IPs for “EDM Mac Studio” (Roon server) as well as all endpoints (2 AirPort Express modules (“rebook n”), 3 RoPieee modules) as noted in the screenshot.
I will begin running tests tomorrow and keep track of any anomaly times.
Daniel- so far so good. I’ve played several long playlists via the same AirPort Express having dropouts and stops before, with no such behavior since turning off Time Machine and locking down Roon device Ip addresses. My guess is that macOS 15 introduced something in Time Machine that made it more intrusive than before, perhaps even at times other than hourly backups. I am not sure if locking down all the Roon device IP addresses made a difference, but it can’t hurt.
I’d like to leave this open a little longer to facilitate more significant tests such as streaming high def music to multiple Roon endpoints over at least an hour. Perhaps you could pull another diagnostic at that time. I will follow up.
Hi @likeanice1903,
I’m glad to hear that Roon is now working properly with your AirPort Express! This thread will remain open for 14 more days by default. If you need more time for testing, you can reset the countdown by commenting again.
Last week and just now (twice, before 10:26 AM EDT) there was a brief dropout upon starting the first track in a playlist. The dropout was long enough for the clock output to go bad from the AirPort Express. Subsequent tracks in the ~ hour long playlist were flawless. Last week it happened only once, restarting the playlist resulted in no further dropouts.
Today it happened twice, so I’m going to reboot the Mac Studio running Roon server and restart the Roon program. This has helped in the past for persistent dropouts. Also I am running the latest Roon SW update. The song title was “Clasicos 1.0: Call Pachanguero” in case you can see anything.
Thanks for sharing the above trace! We did see a few airplay-related errors - one of which our team is already aware of and working on a fix for.
We see the AirPlay device trying to communicate with 169.254.230.0. This is a self-assigned link-local address, which typically means the device lost its connection to the network - apologies if this has been glazed over already, but are you able to test out using a hardwire connection to your airplay devices?
It may help to restart the airplay device as well, if you haven’t recently.
Hi @Benjamin After I rebooted the Mac Studio and restarted Roon, the first track in the playlist still had a dropout. It was a Qobuz track which I deleted (thinking it may be “defective”) and added the same track from Tidal. The playlist, and then another, both ~ 1 hr, then played with no issues.
A cool feature would be if Roon could provide some sort of error rate indicator for each service (Tidal, Roon). Even better some sort of log of service problems.
The two AirPlay devices are indeed wired via Ethernet (see block diagram way above in this thread). Is this what you mean by “hardwired?” I added a switch back to the primary router (not shown in the diagram) so that AirPlay device goes via the switch
Interestingly, Roon has always shown these AirPort devices with a 169.254… address (see screenshots), but the router table shows the manually locked IP. I always wondered why they show a 169… IP in Roon. I unplugged each device one at a time, and they both came back with the same address shown in Roon and the router table.
As an aside, if I close Roon, the AirPort devices disappear from the router table but the Ropieee devices do not.
Could you kindly confirm whether the DHCP server is enabled on the AirPort Express devices?
The 169.254 subnet indicates that the device is unable to get an IP address from the DHCP server. By default, Asus routers set the DHCP lease time to 86400 seconds (24 hours). During this time, the device will receive the same IP address it was assigned previously.
You can try to set up a Reserved IP address in your router settings and then reboot your Airport devices, perhaps then it will pick up the correct IP address, but the 169… IP generally means that the device wasn’t able to get an IP address from the router.
In this network diagram here, is the primary router handling the DHCP assignments and the rest of the routers are in access point mode (no DHCP assignments)?
If you notice the issue occur again, can you please let us know the exact local time + date + track when you observe the behavior? This will allow us to enable diagnostics and take a closer look at that specific timestamp for any errors.
The 2 AirPort Express modules do have “Connect using:” set to DHCP (see screenshot below). The other choices are “Static” and “PPPoE”. However they are both showing the IPv4 address that has been manually assigned in the Asus router.
As seen on the previous screenshot (scroll above) of the Asus router list of “Manually Assigned IP around the DHCP list”, the AirPort Express devices are using the manual IPs assigned in the router. Also if you look at the device list in the router, these devices are shown as “Manual”, not “DHCP” or “Static.”
Given the AirPort Express modules are set up with a manual IP in the router, I assume there is no lease time involved from the router’s “perspective.” I haven’t tried setting the AirPort Express devices to “Connect Using: Static”. Do you think there is any point in doing so?
Regarding the Asus “primary” and “satellite” router configuration, they are set up in the Asus proprietary “AiMesh” mode (see screenshot below), with “Ethernet backhaul”. Both AirPort Express modules do show the router address as 192.168.50.1 (the screenshot below), which is correct. “AiMesh” is somewhat mysterious to me.
I am happy to advise any further issues. Certainly it seems the biggest problem was the Apple Time Machine running on the Mac Studio, which seemed to get worse with a previous macOS update. With that off, Roon performance seems vastly improved across all Roon endpoints.
I changed all the Roon endpoint device configurations from DHCP to Static (the RoPieee devices also were configured for DHCP). I stopped the Roon applications on the Mac Studio and restarted them. The AirPort Express devices still showed “via AirPlay2, 169.254…” on the Roon Audio settings page.
I temporarily disconnected power from one of the AirPort Express devices and checks the Roon Audio settings on the Mac Studio. When I scrolled to the device that was power cycled, I noticed the Roon display (“via AirPlay2, …”) went from a 192… IP back to the 169…IP- maybe as a result of scrolling to where it could be seen at the bottom of the page.
Thanks for the screenshots and the additional info. I was able to look over your latest diagnostics and I do see the 169.254 IP listed there. I also noticed a 403 Forbidden error when trying to pair with the device. I’m going to check with the team regarding these errors and we will get back to you. In the meantime, can you please also confirm if disabling IPv6 triggers any change in behavior?
Noris I disabled IPv6 on the AirPort Express modules and rebooted one of them, as well as restarted Roon. The Roon Settings>Audio page still shows 169.254… IPs, but the router shows 192.168… IPs.
A week ago one of the AirPort devices rendered 2 hour long playlists from various sources and resolutions with no problems, so despite the IP address mystery they seem to work.
Thanks for the additional feedback and for checking the IPv6 aspect. The team is looking into this behavior and we will reach out once we have more details to share, thanks in advance for your patience!
