I incline to believe that David A is right when he states that the difference in network traffic may be caused by the communication errors that occur in the RAAT protocol. I refer to his posts # 159 and # 167:
"
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 problems with this gigabit connection problem? People are not getting that problem with AIR and while those with the problem is noticing problems when dropouts occur, that doesnt 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."
"
The bottom line in all of that is that we expect higher traffic flows in both directions with RAAT because TCP has higher bandwidth requirements and there may also be extra traffic from Devialet to Roon because Devialet needs to send more data to Roon when using RAAT.Although the amount of traffic in both directions, however, the demand placed on the connection is well within the bandwidth capabilities of both 100 baseT and gigabit ethernet connections so bandwidth alone should not be a concern for quality purposes. "
Even with the additional traffic caused by errors, the total amount of traffic should not cause any problems (it is well below bandwidth - see my post # 168).
Today, I have done new tests using a ROON - DEVIALET communication network, with a speed of 100 Mbps and direct connection (no router).
I used two FLAC files at 192kHz and 44.1kHz, respectively. Traffic is higher with the RAAT protocol only for the 192kHz file (here are more errors, I suspect). However, in the case of the 44.1kHz file, the RAAT protocol traffic is
lower than the AIR protocol.
I also remember that I saw in the forum (but I do not know where) that DEVIALET said the product has a general problem with the Ethernet connection, but its effect only becomes visible to the user under certain conditions (one of which is the more traffic great). This assertion seems to be confirmed by the test done today.
In the charts, it is also noted that the RAAT protocol has a much larger traffic at the beginning of the track, which may explain the occurrence of "An audio file is loading slow" error in this protocol.
192kHz AIR + RAAT
[
attachment=3545] [
attachment=3546]
44.1kHz AIR + RAAT
[
attachment=3547] [
attachment=3548]
@
daniel.avasilichioaei - I expect the high initial throughput you've seen with RAAT is due to the Roon Core trying to fill the TCP send window as far as possible. Once the TCP window is full, the measured throughput should settle to a steady state unless there's a need for re-transmissions.
@
daniel.avasilichioaei -very interesting testing results. Have you already sent these findings also to Roon and Devialet? This could be useful information for them both so that they could confirm whether this is related to the audio file loading slowly -problem.
(28-Jul-2019, 09:57)petrik Wrote: [ -> ]@daniel.avasilichioaei -very interesting testing results. Have you already sent these findings also to Roon and Devialet? This could be useful information for them both so that they could confirm whether this is related to the audio file loading slowly -problem.
Yes, today I sent this info to Devialet team, among with all other info that I have on this issue (including here attached full set of measurements).
(15-Jun-2019, 20:15)K4680 Wrote: [ -> ]@Manfred, hi Manfred as I see you use a FritzBox. If you look into the event list, do you find there an entry multicast ... (see picture)?
Yes. IGM Snooping only applies for multicast streams.
(28-Jul-2019, 08:37)daniel.avasilichioaei Wrote: [ -> ]I incline to believe that David A is right when he states that the difference in network traffic may be caused by the communication errors that occur in the RAAT protocol. I refer to his posts # 159 and # 167:
"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 problems with this gigabit connection problem? People are not getting that problem with AIR and while those with the problem is noticing problems when dropouts occur, that doesnt 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."
"The bottom line in all of that is that we expect higher traffic flows in both directions with RAAT because TCP has higher bandwidth requirements and there may also be extra traffic from Devialet to Roon because Devialet needs to send more data to Roon when using RAAT.Although the amount of traffic in both directions, however, the demand placed on the connection is well within the bandwidth capabilities of both 100 baseT and gigabit ethernet connections so bandwidth alone should not be a concern for quality purposes. "
Even with the additional traffic caused by errors, the total amount of traffic should not cause any problems (it is well below bandwidth - see my post # 168).
Today, I have done new tests using a ROON - DEVIALET communication network, with a speed of 100 Mbps and direct connection (no router).
I used two FLAC files at 192kHz and 44.1kHz, respectively. Traffic is higher with the RAAT protocol only for the 192kHz file (here are more errors, I suspect). However, in the case of the 44.1kHz file, the RAAT protocol traffic is lower than the AIR protocol.
I also remember that I saw in the forum (but I do not know where) that DEVIALET said the product has a general problem with the Ethernet connection, but its effect only becomes visible to the user under certain conditions (one of which is the more traffic great). This assertion seems to be confirmed by the test done today.
In the charts, it is also noted that the RAAT protocol has a much larger traffic at the beginning of the track, which may explain the occurrence of "An audio file is loading slow" error in this protocol.
192kHz AIR + RAAT
44.1kHz AIR + RAAT
I have similar results, playing 24bit/192kHz. (Diana Krall - Turning ...)
Roon sent: ~9.7Mbit/s
Roon receive: ~250kbit/s
compared to JRiver MC playing the same file:
MC sent: ~7.9 Mbit/s
MC receive: ~50 kbit/s
I think you see the additional bandwidth required by roon is due to its multicast protocol. The MC network curve is in my environment much flatter then the roon curve. Also MC using in memory play with AIR sounds to my ears in my environment better (not so nervous). Generally I have no issues playing 24bit/192kHz with roon/Devialet RoonReady or MC/AIR. DSD is also not a problem.
Whats about streaming from Tidal or Qobuz using Roon Raat? When I skip a track the first 1-2 seconds are missing!
I am puzzled by this "audio file is loading slowly" -problem. I have experienced this problem from the beginning and I haven't found any solution to it. I have tried different router settings, different routers, different switches (and without switches), different network cables, and running Roon Core on different computers (Windows 10 desktop, Windows 10 Laptop, Roon Nucleus+), but nothing helped.
But... recently I returned my Nucleus+ to my dealer (for a few different reasons) and I received a brand new Nucleus+. So yesterday I plugged the brand new Nucleus+ to the same gigabit network, and to my surprised it worked perfectly. I didn't change any settings in the router or switches. I was capable of streaming to my Devialet without any problems using RAAT on a gigabit network. I tried streaming both 16/44.1 kHz and high res (24/192 kHz) and everything worked perfectly fine.
It is really odd that I can get the RAAT streaming work perfectly fine with my new Nucleus+ but it didn't work with Windows 10 desktop, Windows 10 laptop, or my earlier Nucleus+. I'm puzzled. The root cause for the problem might be something complicated and hard to fix.
(31-Jul-2019, 09:20)petrik Wrote: [ -> ]I am puzzled by this "audio file is loading slowly" -problem. I have experienced this problem from the beginning and I haven't found any solution to it. I have tried different router settings, different routers, different switches (and without switches), different network cables, and running Roon Core on different computers (Windows 10 desktop, Windows 10 Laptop, Roon Nucleus+), but nothing helped.
But... recently I returned my Nucleus+ to my dealer (for a few different reasons) and I received a brand new Nucleus+. So yesterday I plugged the brand new Nucleus+ to the same gigabit network, and to my surprised it worked perfectly. I didn't change any settings in the router or switches. I was capable of streaming to my Devialet without any problems using RAAT on a gigabit network. I tried streaming both 16/44.1 kHz and high res (24/192 kHz) and everything worked perfectly fine.
It is really odd that I can get the RAAT streaming work perfectly fine with my new Nucleus+ but it didn't work with Windows 10 desktop, Windows 10 laptop, or my earlier Nucleus+. I'm puzzled. The root cause for the problem might be something complicated and hard to fix.
Hi Petrik, are also my experiences! With Roon on the MAC or Win PC always the slow loading and dropouts. With Roon Rock and Nucleus + everything is wonderful.
See entry #120
I have an older PC (Gen 4 i5 CPU) running Windows Server 2019 Core which is showing this message as well, but only very very rarely. In most cases when this message comes it is still loading the track. Connection is from PC via optical Ethernet to an Aqvox switch and then to the Devialet.
I'm using AO 3.0 and Fidelizer, maybe this helps. Win 10 has the same behavior, so I think it could be hardware specific (Ethernet adapter).