Audio via RAAT has intermittent dropouts, AirPlay OK from core on high spec'd iMac [Resolved: Jumbo Frame]

Roon Core Machine

2019 iMac 8 core 3.6GHz i9, 40GB RAM, 512GB SSD

Networking Gear & Setup Details

Router: Asus RT-AC68U
Switch: Cisco SG300-28 28-Port Gigabit Managed Switch (currently bypassed)
Ethernet CAT-6 to all streamers

Connected Audio Devices

SoTM SMS-200 Ultra Neo - Roon
Allo Digi One (SPDIF) - Roon and Airplay
Airport express x4 (Airplay2)
Apple HomePod mini

Library Size

21,038 tracks

Description of Issue

My iMac runs my core and I use the endpoints above plus a few computers with a total of 8 zones. Although I routinely use 5 of them. The Allo Digione runs with the Roon endpoint as well as the airplay emulation shairport.

When I stream a track from Roon to the Roon endpoint on the DigiOne, I frequently hear dropouts in the stream. The music could be from Tidal or my own library. How severe the dropouts are varies. Sometimes it unlistenable, other times it’s just noticeable. And sometimes I don’t hear it.

When it happens the iMac is not busy and restarting the Roon core does not help.

However if I swap the exact same stream over to another zone that is the shairport device on the same Allo DigiOne hardware (and effectively stop the Roon stream), then the exact same stream has no dropouts!

On my #1 system that uses the SoTM SMS-200 Ultra Neo I occasionally hear the dropouts. This device can only use Roon OR Shairport, but not both together.

I think there is something about the Roon RAAT protocol that is having an issue with my network. I have bypassed the Cisco switch with the iMac, SoTM and Allo all plugged directly into my Asus router, but this did not help. Both streamers are connected directly via Ethernet CAT-6 installed my a licensed electrician.

Please help. This is driving me crazy.

It has been going on for years. I did have a kernel panic issue with my iMac for ages and I finally fixed this with a hardware fix to the iMac (new logic board), due to a fault with the Ethernet hardware. So now I can’t blame the iMac hardware anymore.

As a comparison I also use Plex from the same library and can stream over 3G/4G to my phone in the car for hours with never any dropouts.

I’d assume your Mac is on Ethernet, not WiFi.

In Mac network duplex setting, remove energy efficient ethernet:

In Asus router setting, enable multicast routing, enable IGMP proxy, disable QoS, disable bandwidth management, disable traffic monitoring. disable any AI features.

Did you ever try having all Roon Core and endpoints connected to the same Cisco switch?

How many years have you been using the AC68U?

1 Like

Yes ethernet and WiFi is currently disabled.

Ok this may be it. I had a manual configuration with jumbo frames enabled and full-duplex (but it did not say energy efficient). I went back to auto setting and it applied the “full-duplex, flow-control, energy-efficient” so I have overridden this with a manual setting of just “full-duplex, flow-control”. It has also reverted to standard 1500 MTU.

With a quick test it sounded good but my spouse is working in that room so I’ll have to wait till tonight to be sure.

On the Asus:

Multicast enabled.
Is IGMP snooping the same a proxy? I could not find a reference to IGMP proxy?

All other QoS and monitoring fluffy stuff is disabled. I learned from my ISP some time ago that you need to hard reset these routers once in a while and restore the configuration otherwise they crap out.

I’ve had the AC68U for 4-5 years. I did hard reset probably over a year ago so it’s probably due. Any recommendations for a replacement welcome.

Is the Cisco switch recommended? I can move the endpoint back there if that is preferred?
I’ve heard the Cisco WS-C2960CG-8TC-L is better for audio?

I’ll let you know how I go tonight.


If you had jumbo frame enabled, this is likely to be the culprit. Please leave the other configuration as is.

Only after everything works with your current configuration, then you can go back to the previous configuration.

I’m having dropout issues with streaming (radio & Tidal) & local library files with the Devialet D250 PRO “Roon Ready” endpoint, which is my main 2Ch system. It starts around 5 to 10 mins into play, once it started, it keeps repeating randomly every few minutes, sometimes multiple dropouts within a song, which makes it unusable.

However, there seems to be no dropout issues with Meridian M218 and Devialet AIR endpoints which are on the same network. It’s strange since Devialet AIR input works on the same Devialet D250 PRO device, which seems to point to some issues with Roon 1.8 RAAT protocol with the Devialet Expert “Roon Ready” endpoint.

Best Regards.

There are various threads and suggestions about this brand, e.g.


I’m aware Devialet had Ethernet network issues & unstable connection to the Roon Core (Nucleus+) via RAAT. The network issue was fixed with the latest Devialet F/W. It’s been working fine until the latest Roon 1.8 update. The audio dropout issues is new to my system and only affecting “Roon Ready” endpoint input to the Devialet.

The Devialet OS/firmware update last year helped but did not completely eliminate dropouts for me when using RAAT over gigabit ethernet from my i7 Win 10 PC running RoonServer. But, when I switched to running ROCK on a NUC 8i7, the dropouts went away completely. No idea why. I made this switch long before Roon 1.8 was released and experienced no issues when I updated to Roon 1.8.

One thing to try is a cheap 100mbps switch in front of your Devialet. That solved the problem completely when I had dropouts from my Win 10 PC running RoonServer to my Devialet Expert Pro.

Wonder why going to 10/100 or NUC 8i7 fixed the dropout, GigE is a pretty mature technology.

I ran and tested Devialet’s 13.2.0 beta version for several months before it was officially released. It fixed the known unstable Ethernet connectivity issue. I had no audio dropouts until updated to the latest Roon 1.8 recently. There’s no faults from the D250 and the Ethernet status looks stable the whole time.

So far Devialet AIR is working fine on the same D250 & no issues with all the other “Roon Tested” endpoints. It seems Devialet AIR works just as well. I don’t see any advantage of using Devialet “Roon Ready” except having to deal with bugs and headaches. The only difference with “Roon Ready” is the signal path shows the D250 internal SAM setting. I also use Meridian 218 as endpoint to the D250, it has MQA supports and slightly smoother sound quality.

“Roon Ready” is supposed to provide a higher level of integration and interoperability with Roon, I wonder how the Devialet Expert got certified?

Using AIR means it can only group with other Devialet endpoints. For me, that’s a huge limitation because my Expert Pro 440 is only 1 of 5 endpoints in my home and the only one that can use AIR. 3 of the other endpoints are all capable of streaming Roon Ready which means I can group my Expert Pro with any or all of them.

Why Roon RAAT to the Devialet Expert Pros still has dropout issues for some is a mystery. Why a 100mbps switch solves that (at least it did for me) is also a mystery. Why others still have Roon dropout issues regardless of endpoint is also a mystery. My gut says it has to do with the vagaries of home networking, but I’m certain Roon RAAT pushes the bandwidth/handshake envelope hence the issues often reported. That strikes me as something Roon will need to address at some point.

Bottom line … until I got my Expert Pro working perfectly with Roon via Rock on a NUC, I was leaning toward replacing the Expert Pro with something more stable. I never even considered dumping Roon.

Hi Peter,

so far so good. I tried both RAAT endpoints last night and again this morning. No dropouts so far. I’ll keep monitoring till the weekend and then I can revert back to using the Cisco switch, but there is no real compulsion as I don’t need to free up ports.

I had no idea about the energy efficient Ethernet option. Good tip!


Good. I’ll declare disabling Jumbo Frame as the resolution.

1 Like

No need to replace an amplifier if you are satisfied with its SQ. Our customers chose to add a streamer in front of it to deal with the network requirements. Some even reported better SQ.

I love my Devialet D250 & I have Roon lifetime subscription so won’t be getting rid of either one anytime soon. There are other setup & endpoints having dropout issues, so my guess is it’s a RAAT issue that Roon needs to address.

I migrated to Roon from Meridian Sooloos. My other endpoints are all Meridian, which are all grouped under Meridian Streaming on Roon. I’m glad I didn’t get rid of the dedicated Meridian 218 endpoint for the Devialet.

1 Like

The thread here shows that it is the network infrastructure that breaks RAAT.

Unless RAAT is marketed as working over broken network, it is not the issue.

I’m not sure how you came to that conclusion, maybe that’s true for the other case. I’m 100% sure my network infrastructure is not broken.

I’ve been in contact with Roon Support and they’re still investigating what’s causing audio dropouts for Devialet Roon Ready.

Not saying your network infrastructure is. My point is simply that if you blame RAAT, you’re blaming the wrong guy.

Have you tried the workarounds of 100Mbps switch or WiFi?

No, I did not try 10/100 switch. Ethernet is an IEEE standard, and GigE is a mature technology. If RAAT over Ethernet cannot work with 10/100/1000 switch, it’s a Roon RAAT protocol or implementation issue IMO.

According to Roon “Roon RAAT is a bandwidth intensive software”, so reducing the bandwidth of the GigE switch by 10X to eliminate dropouts seems counter intuitive.

The Devialet Roon Ready endpoint dropouts only started after the latest Roon update, which points to a Roon 1.8 issue.

My experience with Roon and Devialet supports have been great so far.

There are multiple Roon endpoint options for the Devialet D250 PRO, only the Roon Ready (RAAT) has dropout issues. I’ve switch to Devialet AIR (Devialet asynchronous bit perfect protocol over Ethernet) or use the Meridian 218 endpoint to the D250, both working fine.

I’ve also tried Devialet AirPlay (Apple), no dropout issues.

Just to weight in here as this thread seems to have morphed into a RAAT critic.

RAAT while proprietary appears to be using a mix of TCP and UDP. A capture on the wire reveals it seems to stream via TCP and probably uses UDP for service discovery. RAAT is an application specific network layer built on these established protocols.

You can even seem mention of RAAT in the UDP payload.

The networking should, if is working well, ensure that the TCP stream is delivered to the destination and the data is delivered in order. Of course this does not always happen and re-tries may occur or the socket gives up and is dropped.

However in theory there are a lot of annoying things that can particularly when one or more party decides to adopt a non default or atypical configuration (as was my case above). The reason is both parties and all the networking gear in between needs to support this. Interoperability is the bane of networking engineers.

You could, for example have a very slow web browsing experience because of a misconfiguration. But you may not notice it because it’s not typically a time critical application like streaming audio. With my issue (above) I discovered that this also fixed video corruption issues I was having with Plex. I’m pretty sure it was caused by the same configuration. Not because RAAT was broken or the Plex protocol was broken, but because the networking layers it relied on were compromised with a misconfiguration.

The thing about IP networks is that they are amazingly resilient. Even when something is wrong they can keep on “kinda” working. This is good and frustrating. But it keeps lots of people employed!!!

So it may indeed be that moving down to 100MB/s configuration may bring your overall configuration back to a more supported level for all your networking gear. 100 is more than enough for audio, even Hi res.

1 Like

That’s it.