Devialet Chat

First, thanks to @audio_engr for his very flattering comments about what I came up with. I'll be a little bit more hesitant about that in a minute.

But first, for @"alaw":

The Nucleus and Nucleus+ have 1 ethernet port and 2 USB ports. The USB ports can be used in a number of ways including as a network connection by connecting a USB to ethernet adapter to one of those USB ports and making an ethernet network connection via the adapter. If you do that you will see a second ethernet connection appear at the bottom of the Nucleus web page interface. Connecting your Nucleus to the network that way frees up the actual ethernet port for a direct connection to your Devialet. As for control, the Nucleus has a network connection just as it does if you connect your network to the ethernet port in the normal way and you control the Nucleus in the normal way, either by using an iOS or Android app on a tablet or by running the Roon app on a desktop or laptop computer. You control Roon in the same way as you currently control it, the only difference is in the way you connect your Devialet to the Nucleus.

Now back to my experience. I've noticed improvements in sound quality in the same areas @audio_engr mentioned, I'd just be a bit more cautious about how big the improvements are. I've noticed over many years that we focus on improvements and improvements are always seen as a big thing and since most of us are to some degree regularly seeking improvements in sound quality we make a big deal of them. Our subjective appreciation of improvements tends to be somewhat out of proportion to the actual objective improvement in the sound, simply because the experience of noticing the improvement has such importance for us. Yes, I hear an improvement and yes, I really like it and I'd rather listen to what I'm hearing now than what I was hearing when I was using a switch to connect both my Nucleus+ and 140 Pro to the network but I was also really enjoying the way things sounded when I was listening with the switch in the system. The sound improvements are icing on the cake in my view but they aren't the cake and the cake is the main part of the experience. These improvements make something which was already very good a little bit better and in my experience it's impossible to make something which is already very good better by a large degree. The better the starting point, the smaller the improvements you tend to get and, paradoxically, the more I find myself appreciating small improvements.

Now to the subject of this thread, the "audio file is loading slowly" problem. I don't have any native 24/192 content. It's Friday night here and I figured this connection our on Monday night so I've been running things this way for 4 days with a gigabit speed connection between Nucleus and Devialet. I've played CD quality, 24/44.1, 24/48, 24/96, 176.4/24 and DSD64 in bit perfect mode without running into a problem. I used Roon's DSP engine to convert everything to 24/192 and listened to that for somewhere between 3 and 4 hours without problems before going back to bit perfect mode because I preferred the sound of the bit perfect connection. Roon make the observation that upsampling can improve the sound but also that one reason for not using Roon's DSP to do it is because you've chosen gear which does a good job of upsampling and that equipment manufacturers are in a good position to optimise the upsampling process for their equipment.

So, over 4 days I haven't experience ed the "audio file is loading slowly". That's a positive but I think many of those who have posted on this thread would like to see that result maintained for more than 4 days and that means keeping things running this way for longer and seeing whether or not the good experience continues. Also, some people have reported this problem and others haven't, there seem to be differences in the experience that various people have reported. I'm not going to guarantee that it works for everyone. It's working for me and it's working for @audio_engr which is a good sign. It's not a guarantee that it will work for everyone. If you're having problems and you can set things up this way with a Nucleus, it's worth a try, it will cost you nothing but a bit of time. I haven't tried it with any other server like a normal Intel NUC running ROCK or any other server and I'm not going to make any claims about how it would work with servers other than the Nucleus/Nucleus+. You can try it if you want.

Next, some big caveats on my part. I know nothing about networking and I know even less about setting up manual IP addresses. I put together some sketchy comments I found and tried something and it worked. I have no idea if this is the best way to set up a connection between a Nucleus and a Devialet using manual addresses. If we have any networking experts here who want to throw up their hands in horror at what I'm doing, then please throw up your hands in horror and then put fingers to keyboard and respond with details on how to do it better. I'm not going to complain if someone can make improvements to my process, I'll thank them.

Next caveat: My config file only has the ethernet input active, it's the only input I use. With this direct connection the Devialet is connected to the Nucleus but it is not connected to my wider network so it doesn't show on the network. The Nucleus shows because it is connected to the network via the USB to ethernet adapter. I don't know if it's possible to come up with a manual address setup that lets the network see the Devialet through the Nucleus. It would be nice if that is possible and that's an area where I would really like it if someone can suggest a better way of doing the manual address setup, especially if Devialet start letting us do things via a network interface rather than relying on an SD card for things like configurations.

So, to the method:


- connect the Nucleus+ to your network with the USB adapter just as you're doing and use DHCP addressing.

- open the web interface for the Nucleus+ where you can do things like firmware updates. Down the bottom of the page you'll now see tabs for 2 ethernet connections. Your active USB adapter connection is the second ethernet connection, the actual ethernet port is always the first connection and that's the one you have to give a manual address to.

- look at the address settings created for the second ethernet connection using DHCP. There are 4 items, the address, sub net mask, gateway and DNS server. Copy down the last 3 settings and then copy them into the windows for those settings in the tab for the first ethernet connection.

- that leaves you having to set the IP address for the Nucleus+. It apparently needs to be in a range other than the range your router uses when it sets DHCP addresses. The address for your second ethernet connection is 4 items in an a.b.c.d arrangement. just change the c and d figures so if c is 0, use a 1 or 2 and for d use a number between 2 and 254 so your address for the Nucleus+ port will be something like a.b.1.25.

- now create a new Devialet config file and create a manual IP address for the Devialet. Use an IP address that uses the a.b.1 first 3 numbers and for the last number just pick a different number between 2 and 254 than the one you used for the Nucleus+. The other 3 settings are the same as the ones you used for the Nucleus.

Load your configuration file to your Devialet and you should get an ethernet connection to the Nucleus. It may take a minute or 2 for the Nucleus and Devialets to connect but once they do you should be up and running with a working connection.

So, that's it. As I said, if someone has suggestions for handling the IP address settings better, please post them here. I followed some very sketch comments and they worked but that doesn't mean it's the best way to make the manual connection.

Yes, my ethernet adapter is providing a gigabit connection. It's a USB3 to ethernet adapter. Apparently USB2 adapters only support 10/100 ethernet but USB3 adapters support gigabit ethernet.

What do you mean by "…use it and leave the internal interface unconnected?" I'm not getting what you're asking. Could you be clearer about what you mean?

Hello, maybe the tips help someone!
https://kb.roonlabs.com/Networking_Best_Practices

@audio_engr , @David A ,

I'm curious.... given your two ethernet configurations with the Nucleus, have you tried just running USB into the Devialet from the Nucleus? That would still use RAAT, would it not? Curious on sound quality comparison between using USB in vs ethernet in to the Devialet from the Nucleus.

(17-May-2019, 17:37)mdconnelly Wrote: [ -> ]@audio_engr , @David A ,

I'm curious.... given your two ethernet configurations with the Nucleus, have you tried just running USB into the Devialet from the Nucleus?   That would still use RAAT, would it not?   Curious on sound quality comparison between using USB in vs ethernet in to the Devialet from the Nucleus.

No I doubt that it would be using RAAT over usb. I suspect that both Roon and the Devialet are transfeing audio over USB using an isochronous transfer mode. 

This is completely different from transferring over a packet network, which is what RAAT is for. 

Jean-Marie

(17-May-2019, 14:30)alaw Wrote: [ -> ]@David A  ok, understand. I thought you were using this as a solution for the current Roon/Devialet 1Gb/s network drop out problem, but it’s primarily to split audio and control streams. I will have a play when I get home. Thanks for all the excellent information.

There are servers from firms like Innuos, Antipodes, and Melco which have 2 ethernet connections, one for the network and one for passing the music signal to your chosen endpoint which in our case is a Devialet. They claim that this delivers better sound quality than passing the music over the wider network. Given that we've had people here such as @GuillaumeB  posting about the benefits of audiophile switches I've wondered whether the best solution to dealing with switches was eliminating them as Innuos and those others do by providing a second ethernet connection for your endpoint. I approached this issue as a way of achieving that.

As a side issue, it seems to avoid the gigabit ethernet problem. The connection between Nucleus and Devialet is gigabit as confirmed by the connection speed light on the Nucleus. As I said, I haven't had any issues with the gigabit dropout problem in 4 days streaming the high res source material I have at its native rate or when I tried using Roon's DPS to convert everything to 24/192 for 3 to 4 hours.

And as I said, I'm not claiming this as a fix for the gigabit problem. I think we'd all want to see this running for a longer time and with a lot more people than the current 2 before we started claiming a fix but so far it does seem to avoid the problem. In any event, even if it is a "fix" it's only going to be a fix for those people like me who have their Nucleus close enough to their Devialet to allow them to make a direct connection. It's unlikely to be a practical fix if your Nucleus and Devialet aren't in the same room.

(17-May-2019, 17:37)mdconnelly Wrote: [ -> ]@audio_engr , @David A ,

I'm curious.... given your two ethernet configurations with the Nucleus, have you tried just running USB into the Devialet from the Nucleus?   That would still use RAAT, would it not?   Curious on sound quality comparison between using USB in vs ethernet in to the Devialet from the Nucleus.

@Jean-Marie is correct, Roon does not use RAAT over USB. RAAT is a network protocol using packet transmission. USB does not use packets as far as I know.

@David A: Excellent explanation. Thank you!

On my configuration via router, Roon READY was not working fine (mainly on HRs and MQAs). Roon AIR (bit-perfect asynchronous mode) had no problem at all.

Today I had setup Direct Ethernet (Gigabit) connection between my Roon Core (Windows 10 PC) and Devialet Expert, using a second network card. Then I spent many hours using/testing both Roon READY and Roon AIR...

At the end, I came to two conclusions:

1. Switching to Direct Ethernet (Gigabit) connection made an obvious improvement to Roon READY. Still not perfect, but it is almost acceptable.
   
2. A possible cause for Roon READY issues may be the fact that this protocol is much "heavy" for the network (and devices) than Roon AIR. Since now I have a dedicated network card for Roon Core - Devialet communication, it is easy to compare. Thus (see attached pictures):
   

• Average network traffic from Roon Core to Devialet is almost double for Roon READY versus Roon AIR.
  
• Network traffic from Roon Core to Devialet is very fluctuating for Roon READY, while for Roon AIR it is pretty steady.
  
• There is ~8 times more network traffic from Devialet to Roon Core for Roon READY versus Roon AIR.
  

On the other hand, I didn't notice sound quality differences between Roon READY and Roon AIR.
So, I am wondering: why using Roon RAAT, and not Roon AIR?
I am also wondering why Roon Core playing the same track is sending to Devialet almost a double amount of information  for Roon READY versus Roon AIR?

@daniel.avasilichioaei

Interesting comparison. Like I said before, I know nothing about networking so asking me why there's a difference in the amount of traffic between AIR and RAAT isn't likely to be all that productive but I will make two comments that may mean more to you than they mean to me. Since you've got the software to make those measurements you made I'm betting that you know a lot more about networking than I do because I had no idea at all about how to go about making that kind of measurement in the first place.

Roon have a webpage where Roon talk about RAAT and what their design goals for it were (https://kb.roonlabs.com/RAAT).

Buried in the design goals section is the following statement:

"Audio devices must own the audio clock. Many other protocols get this wrong, including AirPlay. It's not possible for two clocks to agree perfectly. Letting the DAC control the pace of streaming removes the need for a clock-drift-compensation mechanism that is bound to increase cost, decrease sound quality, or both."

If the Devialet is controlling the pace of streaming with RAAT and ROON is controlling it with AIR, then perhaps part of the difference in traffic is due to differing amounts of communication between Roon and the Devialet with the 2 protocols.

As for the increased traffic from Devialet to Roon, another factor may be the amount of data the Devialet communicates. Using RAAT, the signal path display in Roon will give you information about tone control and SAM settings if you're using those adjustments. I don't know whether that information is sent to Roon if you're using AIR but I suspect not. I know the Devialet AIR app never used to display such info back in the days when I was using it before I started using Roon so I suspect that the AIR protocol wasn't designed to convey that information and as far as I know the AIR protocol didn't change when Roon incorporated it into their software. My guess is that with RAAT the Devialet sends more info back to Roon about how it's processing the signal than it does with AIR.

So that's 2 areas with RAAT where the Devialet may be sending more data to Roon than it does with AIR. I have no idea how much data may be involved with that.

When it comes to Roon sending almost twice as much data to the Devialet with RAAT, could that be due to error correction and resent packets due to issues with this gigabit connection problem? People aren't getting that problem with AIR and while those with the problem are noticing problems when dropouts occur, that doesn't tell us anything about how much traffic is being resent due to error correction when the error correction process is working and dropouts are being avoided because of it. It would be interesting to repeat these measurements when the gigabit problem is solved and see whether your results for RAAT change with the fix.

Those are my uneducated guesses.

As to why use RAAT rather than Roon AIR, in my case I hear a sound quality difference and I prefer RAAT. It sounds more natural to me. Roon AIR doesn't sound bad to me, it sounds good and I was quite happy using it before we got the Roon Ready update. I'd still be using it if we hadn't got the update and using it happily at that. We got the update and I did a comparison and preferred RAAT, and I wasn't getting any problems streaming the content I have on my drive at its native resolution so I've stuck with RAAT. I've swapped back to AIR a couple of times since February to see if my feelings have changed and I still prefer RAAT. There's been a poll on the topic of RAAT vs AIR and the last count I saw on the poll had more people preferring RAAT but a reasonable showing for AIR. In my view the options one had to select from were very badly worded and weren't clear in at least one case but even making allowances for that RAAT still seemed to come out slightly ahead on the preferences.

As a point of clarification, when using AIR the Devialet does indeed dictate the rate of data transfer, not the sending device or software.  I guess there is a clue in the name, with the "A" in AIR standing for "Asynchronous".  In the past I have tried setting a fairly high buffer in AIR and you can then remove the Ethernet cable when music is playing, and for a couple of seconds the music continues playing.  The Devialet runs down whatever is left in the buffer even when disconnected to whatever put the data there.  So clearly the Devialet is in control.

From the temple of truth:

AIR offers two different set-up options, asynchronous BitPerfect or asynchronous fixed broadband, to ensure the best possible service quality in even the most unreliable network environments. Asynchronous BitPerfect mode provides optimal audiophile-grade conditions: music is transferred from your computer or smartphone to the amplifier with zero alteration to audio samples. This mode of transfer occurs at the exact same rate as Expert Pro digital-analog conversion rather than the speed imposed by your computer. The amplifier therefore dictates computer behavior rather than the opposite, with AIR intelligence split evenly between the two devices.
Smart buffer management guarantees minimal latency and optimal capacity availability. It’s as though your music were already pre-downloaded and available from RAM memory immediately upstream from digital-analog conversion.
By dramatically clearing the pathway from audio content source to analog conversion, AIR keeps overall digital jitter to an absolute minimum. For radically superior clarity and transparency all throughout playback.