Audio file loading slowly since Devialet RAAT

I haven’t had this problem when the Roon UI has been shut down. I’ll keep testing.

not sure if someone has run wireshark to record the pakets and analyze them. I did, and the result is very interesting:

Test 1 (ROCK on i7 NUC and ROCK on VMware):
removed the Power from Devialet and powered again, restarted roon, connectivity 1GB, after a few minutes packet retransmission happen. First, one all few seconds and from time to time is coming more till collapse. Reboot of Devialet and roon is necessary

Test 2 (ROCK on i7 NUC and ROCK on VMware):
removed the Power from Devialet and powered again, restarted roon, connectivity 100MB Full duplex, after a few hours packet retransmission happen. First one all few seconds and from time to time is coming more till collapse. Reboot of Devialet and roon is necessary

Test 3 (Windows 10 on VMware ):
removed the Power from Devialet and powered again, restarted roon, connectivity 1GB, after a few hours packet retransmission happen. First, one all few seconds and from time to time is coming more till collapse. Reboot of Devialet and roon is necessary

Test 4 (Windows 10 on VMware):
removed the Power from Devialet and powered again, restarted roon, connectivity 100MB Full duplex, after days no paket retransmission nor duplicated ack’s.

For me it looks like a ethernet buffer problem in the devialet device.

Update:
Hmm, I miss those big pakets with push Flag in a GB environment, or ROCK with 100MB
image

Given that we’ve heard nothing back from Roon @support, I kinda suspected it is a Devialet problem that hopefully can be resolved with an Expert Pro firmware and/or OS update. I’m running RoonServer on Win 10 with no problems at all since switching to 100 mbps. Good to see that confirmed in your test.

More disturbing is that your tests indicate it is still a problem with ROCK. I had been contemplating an upgrade to a NUC running ROCK. Glad I waited!

Just a reminder, it works fine with WiFi, wired to NUC, wifi to Devialet.

May I ask if there is any update on this case so far?

2 Likes

Hello Everyone,

I just wanted to provide an update here as a few users have requested.

We understand that some (but not all) users with Roon Ready devices from Devialet are experiencing these symptoms, and while we haven’t been able to reproduce this issue in-house (either during the certification process or since), we are committed to getting this resolved.

We have spoken with Deivlaet regarding this issue and provided them with technical information needed to investigate this further. They are currently looking into this, and we’re looking forward to hearing the results of their investigation, and helping in any way we can. We don’t currently have any indication that this is related to Roon generally or RAAT specifically, but obviously we’ll do whatever we can to get this stable and resolved for Roon users.

As soon as we have more information from Devialet, we’ll update this thread, and users can also feel free to directly reach out to Devialet with questions about this issue.

We appreciate everyone’s patience while this investigation is underway. Thanks!

– Noris

@Noris - your comment that you have not been able to reproduce this internally is surprising. Please clarify - can you stream hi-res music to a Devialet Expert Pro on a gigabit network using RAAT without any issues? This problem manifests itself far more frequently when streaming hi-res (24bit, 96kHz or 192kHz).

The feedback I received from Devialet initially indicated they, also, couldn’t reproduce it, but later acknowledged that they have seen a similar issue at gigabit network speed. I am able to eliminate the problem by forcing network speed to 100 mbps into my Devialet.

Perhaps it’s not surprising that Roon have not been able to duplicate the issue.

I commented some time ago on Devialet Chat that I had never had the problem with my 140 with content at CD resolution, 96/24, 176.4/24, or DSD64 but that I hadn’t tried 192/24 as I had no content at that resolution. I later commented that around 4 weeks ago I tried a direct ethernet connection between my Nucleus+ and my 140 (network connection via a n ethernet to USB3 adapter) and immediately ran into the problem with CD resolution content so I reverted to my previous setup using a Netgear GS105 switch and the issue went away,

Late last week I replaced the GS105 switch with an Orbi satellite and had no problems with any of the different resolution format content I have on the Nucleus+ and decided to really give things a “torture test” so I used Roon’s DSP to convert everything to 192/24. I played a range of CD quality, 96/24, and DSD content for over 4 hours without problems. I ended up swapping back to sending everything in bit perfect mode because I decided I preferred the sound of bit perfect mode slightly.

Yesterday I had another go at setting up a direct ethernet connection between my Nucleus+ and my 140 but this time I set up manual IP addresses for both the Nucleus+ and 140 for the direct connection. I’m still using DHCP on the network connection to the Nucleus+ via the USB adapter. I’ve only done about 3 hours listening with this setup so far but when I had no problems with bit perfect output from the Nucleus+ I again used Roon’s DSP engine to convert all content to 192/24 and played 2 records without problems before I went to bed. I haven’t fired up the system this morning to see whether my luck, or whatever it is, is still persisting.

If we stop and think about it, there’s no problem with a wifi connection to the Devialet yet there is a problem with a wired connection. That’s weird to my mind, and the only difference is generally an ethernet switch of some kind between the server and the Devialet. I had no problems with a GS105 switch, I ran into problems with a direct Nucleus+ to Devialet connection with a setup using DHCP and the wifi input on my 140 active, no problems when I reverted back to the GS105 switch, no problems with an Orbi satellite instead of the GS105, and no problems with a direct Nucleus+ to 140 connection using manual IP addressing. All connections have been gigabit ethernet.

I’m inclined to agree with @noris. This isn’t a Roon problem and I’m not certain the problem is essentially a Devialet problem. I’m currently inclined to think it’s related to what we stick between the server and the Devialet and probably not so much the device as something to do with network settings for the device.

But as far as I’m concerned here with my system, as of last night with my new direct connection arrangement between my Nucleus+ and my 140, I couldn’t be happier. Everything is running without problems, it sounds great, and I’ve managed to get rid of an intermediary device in my signal path. OK, 3 to 4 hours and 3 or 4 records doesn’t guarantee that my current situation is still going to work long term without problems but with this setup, and with the Orbi satellite, I’ve thrown everything I can at it including 192/24 courtesy of Roon’s DSP engine and I haven’t had a single issue at any resolution. I think that shows that it may well not be a Roon problem or a Devialet problem but rather a problem elsewhere in the network and possibly setting related.

David, what comprehensive testing :+1: I would speculate that the problem lies with Devialets implementation of Autonegotiation, which only applies to wired and can often go astray between different manufacturers, resulting in a link mismatch and low throughput. I dunno though, I just hope the Devialet team is on it.

1 Like

I’m also quite convinced the issue lies with Devialet. But to be honest, I have more confidence in Roon at least identifying the root cause of the issue - even if they aren’t in a position to fix it. That’s the main reason for my concern that they have been unable to duplicate the issue despite many users experiencing it. Strange.

Mike and Michael,

I’ll accept that the fact that the problem exists with an ethernet connection but not a wifi connection to the Devialet tends to point the finger at a Devialet problem.

Michael makes the point that he’s concerned that Roon have been unable to duplicate the problem. If the problem is linked to a network device located somewhere between the server and the Devialet, it may require a setup with the same intermediary device or devices in order to duplicate the problem and that is a big ask given the number of different intermediary devices available for us to put between server and Devialet. I don’t know how many makes of different switches and routers there are being used by Devialet owners but whatever that number is we can multiply that by some other number when we start to consider the number of different models of switch and router available from each manufacturer.

Then there’s the issue of settings for each device since most switches and routers are configurable to some degree.

Replicarting a problem isn’t easy if the problem only occurs with some specific combinations of devices and settings and there’s a huge range of combinations of devices and settings available for testing. You can’t replicate the issue until you get the correct combination. I you just happen to have that combination in your system you don’t have to go looking but if you don’t get the problem in your system and you have to start playing around swapping devices and playing with different setting options in order to replicate the issue replication can be a lot more difficult.

Mike suggests the problem lies with Devialet’s implementation off Autonegotiation (I know nothing about IT and networking and have no idea what that is) but if it can go astray between different manufacturers causing mismatches and low throughput, why should we automatically assume that the problem is with Devialet’s implementation rather than something related to the network device? I’m not saying that it isn’t a Devialet issue but I am saying that if the problem lies in the way that the Devialet and the network device communicate and some people have the problem but others don’t, it’s also possible that the issue isn’t with Devialet’s handling of Autonegotiation but rather with the intermediary device’s handling of it. Like the old saying goes, “it takes two to tango” and either partner can get it wrong, as can both.

I’ve got no idea what the cause of the issue is. As I said, I know nothing about IT or networking. All I can do is to try to apply logic to the different reports I’ve read and to my own experience and the only thing I think we can be certain of is that if some people aren’t having the problem and some others are, then the cause has to lie somewhere in a specific combination or combinations of Roon, Devialet, and intermediary network devices and the settings for those devices.

The only thing I can add to my earlier post is that it’s now 7.30 am here in Australia, two and a half hours after my earlier post, and I fired up my system before starting to make breakfast and everything is still working fine. I’ve gone back to bit perfect mode which I think sounds better than having Roon’s DSP convert everything to 192/24 but I did listen to the first half of my first disc of the day at 192/24 without issues.

That is very interesting. I am having a very similar setup (Devialet 1000 Pro, Nucleus+, Netgear Orbi, Cat6 cables and a few different gigabit switches). I have experienced a lot of problems with this setup when using Ethernet, it is basically impossible to play any high res track. I tried different network configurations, different switches and network cables, but nothing solved these problems.

Fortunately things work quite ok when using WiFi instead of Ethernet.

When reporting the issue to support, we should probably include router/switch type make, managed/not, to help paint a picture of the equipment this is affecting. Perhaps a pattern will emerge?

Petri,

Our setups sound similar prior to my shifting to a direct connection between the Nucleus+ and my 140 but there’s room for several differences which may be related to your problems.

When I was using a switch and not experiencing problems my network setup was as follows:

  • Orbi hub

-cat 6 wired connection to the room in which the audio system is located

-switch, either a Netgear GS105 or an Orbi satellite (both worked for me)

  • Audioquest Vodka ethernet cables to Nucleus+ and my 140.

Assuming a similar network setup the 2 things I’d be looking at are the switch and your Orbi settings. While I didn’t have problems with the GS105 switch I had a preference for using the Orbi satellite so if you’re using an Orbi network can you replace the switch you’re using with one of your satellites and connect your Nucleus+ and 1000 Pro to the satellites ethernet ports? As far as settings go, Roon have a “Networking Best practices” document (https://kb.roonlabs.com/Networking_Best_Practices) which has the following comment on Orbi networks:

" Netgear Orbi Routers

If you’re making use of an Orbi router, we recommend unchecking Disable IGMP Proxying in your router’s settings. This setting can interfere with the ability for Roon Remotes to connect to the Roon Core."

I don’t know if that affects this issue but I have that setting unchecked in my settings. I don’t think I have changed any of my other router settings.

Thank you for the help. I have tried following things so far:

  1. Connecting Devialet and Nucleus+ to the Orbi router
  2. Connecting Devialet and Nucleus+ to the Orbi satellite
  3. Connecting Devialet and Nucleus+ to a switch (Netgear GS108 unmanaged gigabit switch) and then connecting the switch to the Orbi satellite
  4. Enabling / disabling the IGMP Proxying setting. This setting didn’t make any difference.
  5. Network cables. I use standard CAT-6 UTP cables. I bought couple new ones, just to confirm that the earlier cables weren’t broken. This didn’t make any difference. I haven’t tried any fancy network cables like the Audioquest.

It’s obvious why this issue is a mystery. There’s nothing obvious to pick on as a potential issue.

Some things I didn’t mention are that in my configuration I only have the ethernet input active and I don’t have a SAM profile loaded. Those things shouldn’t make a difference but perhaps there’s a bug related to some combination of Devialet settings.

I don’t know how you go about comparing 2 cases like ours with quite similar setups in many ways and quite different outcomes. There has to be a reason for the problem, and it has to be something that exists in the physical setups and/or various equipment settings for those people with the problem and which isn’t present in the setups and settings of those who don’t have the problem but identifying just what it is obviously isn’t simple.

Petri,

Bizarre thought, don’t know if it could be a possible issue or not: where is your music stored? All of my music, apart from what I stream from Tidal, is stored on an internal SSD inside my Nucleus+ so I’m not dealing with music stored on external drives. Are you using an external drive, either attached to a USB port on your Nucleus+ or on a networked drive somewhere?

I’m using an internal SSD inside my Nucleus+… It doesn’t seem to matter where the music is streamed from (internal SSD, Tidal, Qobuz).

No, the problem appears to be strictly a networking one, specifically ethernet link speed to the Devialet. If you can force the link speed to 100M/s, or simply use WiFI, you’ll not have an issue.

suffered from the same issue and figured that I could search for some solutions here in the forum. Turns out I am not the only one with the issue described here. And indeed, it all started once the Roon Ready Firmware was installed.

And I can confirm that switching to WiFi fixed it. I didn’t bother trying out a 100mbit switch, as I would need to place the 100mbit switch between my 1gbit switch and the Devialet, which would be ridiculous