Devialet Chat

(06-Jun-2019, 22:31)Manfred Wrote: [ -> ]

(06-Jun-2019, 21:57)mdconnelly Wrote: [ -> ]@Manfred - That is quite in interesting network!    To expand on @Flashman 's #2 question.... if you set Port 2 into your 220 Pro to 1Gb instead of 100 Mb, would you get the dropouts and "Audio file loading slowly..." errors on hi-res music?

If it was 1Gb I got the" Audio file loading slowly..  " errors. But setting it to 100 Mb was not enough. I had to disable "autonegotiation"  on two ports. 

Okay, I see that you also had to disable auto negotiation on the port fed by the router.  Clear enough.

@Manfred detailed switch settings table and the questions following triggered my memory. There was a mention of auto negotiation some time back so I did a search.

In post #142 of this thread @K4680 had a description of network problems arising from the auto negotiation setting and recommendations. As I've said before, I don't understand networking at all but one of the things @K4680 says in that post is "Gigabit Ethernet (1000Base-T, 1000Base-SX, 1000Base-LX) is always transmitted only full duplex. Full duplex is only available with switches." If gigabit ethernet is always transmuted only full duplex then from the way I read his other comments the auto negotiation setting should be irrelevant for gigabit connections because auto negotiation appears to be an alternative to full duplex. The auto negotiation setting will therefore make a difference with a 100 MBPS connection but that setting shouldn't be an issue with a gigabit connection so it's not relevant to the gigabit speed connections. I could easily be reading that wrong so hopefully he will comment on this.

The other setting of interest to me in @Manfred 's table is the Flow Control setting. As I've said previously, Roon have a page on 'Best Networking Practices". There's a section on managed switches which contains the following information:

"Managed switches can be very robust, but they are often designed for professional installation, so in many cases the out-of-box configuration is not right. If your switch has a “flow control” setting, please make sure that it is enabled. Also, make sure that the switch is not performing any sort of throttling that might impact communication between cores, storage, remotes, and/or audio endpoints. Finally, ensure that the switch is configured to pass multicast and broadcast traffic. If in doubt about any of this, try temporarily replacing your managed switch with a “dumb” switch to see if things improve."

Given that Roon recommend flow control be enabled, I wonder about the settings for ports 3 and 4. The server appears to be connected to port 3 so Roon's statement suggests that flow control should be enabled on that port. Perhaps that setting is part of the reason for the issues @Manfred reports with a gigabit connection. He also has auto negotiation enabled on that port. My reading of @K4680 's comments back in April suggests that ports 2 and 3 should have identical settings for flow control and auto negotiation and the settings shown for port 2 look to conform with his suggestions. I wonder whether changing those 2 settings on port 3 to match port 2 would improve the performance of a gigabit connection.

As I keep saying, I don't understand this stuff. All I'm trying to do is to match up what different people say, look for differences, and highlight those differences for consideration.

Re my post above:

I can run a gigabit speed connection directly between my Nucleus+ server and my 140. No switch or router or anything between ethernet port on Nucleus+ and ethernet port on the 140. No router or switch settings to consider, in fact no settings I can make or alter at all. I can't change flow control or auto negotiation behaviour, neither the Nucleus or Devialet has settings to control those things. As stated several posts above, this is a virtually trouble free connection UNLESS I stream 192/24 content to the Devialet. There are virtually no problems at any other resolution.

Network is obviously part of it but what's the difference between 192/24 and other resolutions that makes 192/24 almost act as a switch turning the problem on? I haven't noticed problems at 176.4/24 but problems seem to always show up at 192/24.

(06-Jun-2019, 20:38)Flashman Wrote: [ -> ]

(06-Jun-2019, 20:24)Manfred Wrote: [ -> ]I started my Devialet Journey with D170 now D220Pro CI. With D170, AIR, Win7 everything works fine up Win 10 was introduced. With D220 Pro and the CI module, UpNP did not work - stuttering, AIR with JRMC did not work unstable, stuttering and also as I started with ROON, ROON RAAT did not work "Pause" during playback, until I found the following solution for me:

I have a managed Linksys switch, where my Devialet is connected to (see attached architecture overview figure). 


If I configure my switch according to the following table everything works UPnP, AIR and RAAT:

Manfred, would I be correct to surmise that the following four things made your system workable:
1) Managed switch
2) Restrict port for Devialet to 100Mbps
3) Disable auto negotiation for Devialet port
4) Enable flow control for Devialet port

Also, have you had ANY problems with this set-up when using Roon?

Thanks.

1) Managed switch -yes
2) Restrict port for Devialet to 100Mbps - yes
3) Disable auto negotiation for Devialet port -yes
4) Enable flow control for Devialet port -yes

+ that be my environment, I had to diasable autonegotiation also on the Repeater port and enable Flow Control

(06-Jun-2019, 23:24)David A Wrote: [ -> ]@Manfred detailed switch settings table and the questions following triggered my memory. There was a mention of auto negotiation some time back so I did a search.

In post #142 of this thread @K4680 had a description of network problems arising from the auto negotiation setting and recommendations. As I've said before, I don't understand networking at all but one of the things @K4680 says in that post is "Gigabit Ethernet (1000Base-T, 1000Base-SX, 1000Base-LX) is always transmitted only full duplex. Full duplex is only available with switches." If gigabit ethernet is always transmuted only full duplex then from the way I read his other comments the auto negotiation setting should be irrelevant for gigabit connections because auto negotiation appears to be an alternative to full duplex. The auto negotiation setting will therefore make a difference with a 100 MBPS connection but that setting shouldn't be an issue with a gigabit connection so it's not relevant to the gigabit speed connections. I could easily be reading that wrong so hopefully he will comment on this.

The other setting of interest to me in @Manfred 's table is the Flow Control setting. As I've said previously, Roon have a page on 'Best Networking Practices". There's a section on managed switches which contains the following information:

"Managed switches can be very robust, but they are often designed for professional installation, so in many cases the out-of-box configuration is not right. If your switch has a “flow control” setting, please make sure that it is enabled. Also, make sure that the switch is not performing any sort of throttling that might impact communication between cores, storage, remotes, and/or audio endpoints. Finally, ensure that the switch is configured to pass multicast and broadcast traffic. If in doubt about any of this, try temporarily replacing your managed switch with a “dumb” switch to see if things improve."

Given that Roon recommend flow control be enabled, I wonder about the settings for ports 3 and 4. The server appears to be connected to port 3 so Roon's statement suggests that flow control should be enabled on that port. Perhaps that setting is part of the reason for the issues @Manfred reports with a gigabit connection. He also has auto negotiation enabled on that port. My reading of @K4680 's comments back in April suggests that ports 2 and 3 should have identical settings for flow control and auto negotiation and the settings shown for port 2 look to conform with his suggestions. I wonder whether changing those 2 settings on port 3 to match port 2 would improve the performance of a gigabit connection.

As I keep saying, I don't understand this stuff. All I'm trying to do is to match up what different people say, look for differences, and highlight those differences for consideration.

There is a long post in the roon chat from me:

roonlabs chat

@Manfred

OK, read the thread on the Roon site. YOu've tried a lot of things but I can't see that you ever tried having identical Flow Control and Autonegotiation settings on port 3 (server) as you now have on port 2 (D220). As I said, @K4680 's post suggests that identical settings for both devices is desirable, that different settings on both devices can cause issues, and that having auto negotiation turned off is desirable. Also Roon themselves recommend having flow control enabled so having it disabled for the server does not appear desirable.

Further to my initial response to @Manfred, his response, and my immediate reply above, I'm going to toss out a theory for comment.

The Theory:

We have 2 separate issues going on.

First, some "background" points I've noticed that I think are relevant"

- Networking problems manifest themselves in things like dropouts and there's a lot of different networking issues that can cause dropouts. Roon themselves identify several general things and several other things specific to certain network devices that can cause problems with Roon that can show up as dropouts.

- RAAT uses TCP/IP and more data is transmitted in the process than gets transmitted when using other protocols such as AIR.

- More data is transmitted with high resolution files than with lower resolution files.

- The maximum amount of data the Devialet will receive is therefore going to occur when we stream a 192/24 file (highest resolution a Devialet can handle) using RAAT.

- Finally this problem crops up with RAAT but not with other networking protocols, and with ethernet but not with wifi. Other connection methods (USB, coax/optical, AES/EBU) aren't affected because they don't involve the network. This is purely a network issue, purely a wired network issue.


So, we've got a pool of Devialet owners using ethernet connections to their Devialet's, some of whom are having problems and some of whom aren't. Some of those have networks with some of the network issues identified by Roon (eg @Manfred got improvements when he changed the auto negotiation and flow control settings of his switch for the port his D220 is connected to) and some of those have networks without those issues present.

And we know that some of the pool of Devialet owners using ethernet connections get this problem and some don't. Of those who get it, some report problems with files of lower resolution than 192/24, some only with 192/24.

I think it's possible that:

(a) the Devialet has an issue handling the amount of data involved with a RAAT stream arriving over a gigabit connection.

(b) people with networks which don't have other issues of the sort identified by Roon who get the problem only notice it with 192/24 content or mostly with 192/24 content and rarely with lower resolution content.

© people with networks which have issues of the sort identified by Roon notice dropouts with 192/24 content and with lower resolution content but the reason they're noticing it with lower resolution content when they didn't notice it before is because the higher data amounts being transmitted with RAAT are sufficient to trigger dropouts due to the network problems and the lower amounts of data being transmitted using AIR aren't.

(d) both the Devialet issue in (a) and the separate networking issues in © show up as dropouts. There's no way of telling by listening whether a dropout is caused by the problem in (a) or the problem in © but they both get regarded as the same issue because both started to occur with the implementation of RAAT.

Note that we've had at least 1 person claim that RAAT is unusable, period, even at 100 MBPS while others find dropping the connection speed to 100 MBPS solves the problem. I think dropping the connection speed to 100 MBPS is a workaround solution for the Devialet problem in (a) but it doesn't address the network issues of © which require changes to the network settings.

I think the Devialet specific problem in (a) relates to the speed at which the data is received (I suspect that wifi reception is either occurring at lower than gigabit speed or that there's a difference in how the Devialet handles wired and wireless signals which result in the issue not occurring with wifi). I wondered whether it may be a buffer size problem but if 192/24 works with a 1000 MBPS connection and not with a gigabit connection then buffer size can't be an issue because the same amount of data is going into the buffer. Reception speed seems to be the only obvious variable.

That leads me to predict that a fix for the Devialet problem won't solve all of the problems for some people because they will still need to fix their network issues which didn't start to show up prior to the implementation of RAAT.

For those having problems, especially problems at lower resolutions than 192/24, then try reducing the connection speed to the Devialet to 100 MBP but if that doesn't clear things up then start looking hard at your network for issues of the sort identified in Roon's Best Networking Practices document and fix them. If you've got a managed switch and changing settings doesn't help, then try an unmanaged switch.

Finally, a possible explanation for why this didn't show in Roon and Devialet's testing: they did their testing on networks with settings that didn't create problems so they didn't notice anything at resolutions less than 192/24. You don't test to see if something works over a network that is known to cause problems because you then wouldn't be able to tell whether the problems you notice are the problems with your network or problems with what you're testing. If you've already told users about those network problems, and Roon had because they affect all network streaming, not just RAAT, then you've got a right to expect that people will already have looked after those things. With 192/24 content I've noticed issues immediately on one occasion and only after a period of problem free play of well over an hour on another occasion. Maybe they didn't listen long enough at 192/24 for the problem to crop up in their systems. There are always time constraints on testing anything.

Hello @David, again briefly summarized:

1. Half duplex and full duplex
Half duplex Ethernet is based on the CSMA / CD method. It is the original Ethernet up to 10 Mbps. Full-duplex Ethernet is a further development called Fast Ethernet and dispenses with CSMA / CD. All other Ethernet developments also work in full-duplex mode. The stations communicate directly with each other via point-to-point connections.
Because Fast Ethernet typically works in full-duplex mode and thus does not use CSMA / CD, additional flow control is required. There is a separate standard for this: IEEE 802.3x (Flow Control).
(CSMA / CD - Carrier Sense Multiple Access with Collision Detection)

2.Flow Control
Because Fast Ethernet typically operates in full-duplex mode and thus does not use CSMA / CD, additional flow control is required.
The reason: If a host gets too many data packets and no longer complies with the processing, then there is a risk that the data packets are partially discarded. With the flow control, this host can signal the remote station to pause transmission. The affected host sends the causer a pause package. Either to a specific multicast MAC address or directly to the MAC address of the originator. In the PAUSE package is then the desired waiting time.
For example, a switch has 32 Gigabit ports, but only 10 Gbit / s of internal bandwidth. With a PAUSE package, the switch can tell the hosts to send at a slower rate. If the hosts stick to it, the switch discards fewer data packets. This prevents the network from being flooded with repeatedly sent data packets.

3.Auto-negotiation
With auto-negotiation, Ethernet hosts can automatically detect the Ethernet variant of the remote site at the other end of the line. Often, auto-negotiation is also referred to as auto-sensing.
Auto-negotiation became necessary because the transition from 10Base-T to 100Base-TX usually ended in a mixed operation. For this reason, Fast Ethernet components consistently dominate auto-negotiation.
To avoid problems with auto-negotiation, one should operate the network stations either with auto-negotiation or set to a fixed transmission mode. Problems usually only occur when mixing full-duplex and half-duplex components.

4. Every home network has a different constellation, a troubleshooting is time-consuming and it takes know-how!
To make such a general error diagnosis over a network, which one knows only from descriptions and statements, will run in nirvana and deliver no reasonable results!
Sorry, opinion from years of experience in the business!



PS.
What was not mentioned yet are network hardware defects:
-Defective cables
-Kinked cables, or bruises
-Interruptions in the cable
-Wrong mounted plugs, or network outlets
-Defects switch (not immediately recognizable)
.................

@K4680

Thanks for that. You confirmed what I've stated a couple of times, that I really don't know anything about networking :-)

Most of that didn't make much sense to me, my ignorance of networking technology/practice rather than your explanation. What did come through is your point 4 which is that things can get very individual and that not every system is going to handle things in the same way, something I had already surmised, and that trouble shooting takes time which is becoming obvivous given the time being taken for Devialet to come up with a fix.

I still think we may have 2 problems showing up in the reports here, a networking problem and a Devialet specific problem. That would explain why some people seem to get significantly worse issues than others. The Devialet problem is a constant in all cases while the networking problem is a variable.

(07-Jun-2019, 20:36)David A Wrote: [ -> ]@Manfred

OK, read the thread on the Roon site. YOu've tried a lot of things but I can't see that you ever tried having identical Flow Control and Autonegotiation settings on port 3 (server) as you now have on port 2 (D220). As I said, @K4680 's post suggests that identical settings for both devices is desirable, that different settings on both devices can cause issues, and that having auto negotiation turned off  is desirable. Also Roon themselves recommend having flow control enabled so having it disabled for the server does not appear desirable.

Methodology was:

First I had the managed switch only for the connection to the Devialet (Autonegotiation = disabled, Flow Control enabled). The managed switch was then connected to a unmanged switch  (Autonegotiation = enabled, 1Gb). Eeverything works. Then I moved port by port to the managed switch. Yes I have not testet port 3 with flow control enabled because it worked without it, its auto negotiated.