Getting dropouts when upsampling with Roon to DSD512 and outputting to opticalRendu; thoughts?

[The Computer Audiophile]

Hi Jim, this is interesting because it works for much fo the time, until it stumbles. 

 

I really don't think it's the i9 sonicTransporter stumbling because my Intel i5 8400T QNAP NAS can handle the same DSP you're using, sending to the full version of the opticalRendu. 

 

My first thoughts are that it's the Rendu being overwhelmed with data. Usually Roon won't do this because of how Roon implements flow control. This is the very reason why this version of the Rendu only works with Roon. You could also try to make sure flow control is enabled on your optical switch, unless you're going straight from the sonic transporter to the Rendu without a switch. 

 

If you're running direct from the i9 sT to the Rendu, that's a configuration I know people use and can be recommended, but I'd never do it personally. 

[The Computer Audiophile]

You can see the CPU performance comparison between my NAS and your sonicTransport here - https://cpu.userbenchmark.com/Compare/Intel-Core-i9-9900K-vs-Intel-Core-i5-8400T/4028vsm475176

 

 

[The Computer Audiophile]

24 minutes ago, jiminlogansquare said:

I do indeed have the SonicTransporter i9 directly connected to the opticalRendu. Any thoughts or suggestions on how/where to add and configure a digital switch would be appreciated! Could I just stick a switch between the ST and the oR as a means of adding flow control? Other than these two devices, my network is copper Ethernet, not fiber optic.

 

First, I don't want to say that it's the sonicTransporter causing the issue or that it's for sure this direct wiring. I know the Sonore and SGC guys very well and they know their stuff. However, I just wouldn't wire it the way you have it wired. You have two network paths on that machine. I'm sure Andrew configured the OS to use this type of config without issue, but I just wouldn't use it this way. That's just me. 

 

You could test out if this is the issue by using a simple switch like this $110 TP-Link (TL-SG2210P) - 

 

https://www.amazon.com/TP-LINK-TL-SG2210P-8-Port-Gigabit-Switch/dp/B0141JX92G

 

You could wire the Transporter to the switch via copper, and the oR from the switch via fiber. This way you don't have to purchase more SFP modules. 

 

If it was me, I'd run fiber from the Transporter to the switch, and fiber from the switch to the Rendu. I wouldn't use the Transporter's copper cable in this config. I'd run copper from your router to this switch, so it's connected to the Internet. 

 

 

[The Computer Audiophile]

9 minutes ago, jiminlogansquare said:

Thanks. I happen to have one unused SFP module lying around, so could get one more and try your preferred approach. Presumably the switch will have straightforward directions on how to set flow control? Networking is NOT one of my strong suits.

My guess is that switch is pretty easy to configure, if it needs it at all. 

 

In the past @plissken has been very gracious with his time and helped walk people through this stuff if needed. I will certainly help as well. This isn't rocket science. 

[The Computer Audiophile]

7 minutes ago, plissken said:

I don't see how a switch with flow control would improve a point to point link.

 

Play at DSD 256. If the ST is Linux based I would see if you could SSH to it and run TOP during playback.

If the Transporter is sending too much too fast, flow control will solve the issue. 

[The Computer Audiophile]

19 minutes ago, plissken said:

 

That should managed up stack though I would think. I would change to DSD256 sampling and see what happens first.

There’s also the potential issue of running one interface to the Rendu and another to a switch like he’s currently doing. Should be ok, but often isn’t. 

[The Computer Audiophile]

13 minutes ago, plissken said:

Flow control is a congestion mitigation mechanism. If there is congestion on the wire the preference with Flow control is to send a pause frame to tell a sender to back off. This is for when there are multiple Tx/Rx sources saturating a link. We would rather pause, than drop traffic (creating a resend and even more traffic and more congestion).

 

I doubt DSD 512 is capable of saturating at 1GBe link. So I don't think it's warranted.

 

But if there is a routing issue and people are multi-homing like described then going to a more traditional flat network like you suggest would make sense.

This is where you’re too smart for your own good :~)

 

I can saturate the link with one server sending to a single Rendu easily. I’ve done it and reported it. The Rendu has a Gb interface but internally it isn’t capable of that speed.  
 

When using HQP, I have to enable flow control on my switches to make it work. @Miska has said he won’t change how HQP works because flow control should be enabled on the switch and it resolved the issues. That’s HQP and not Roon of course, but it illustrates my point with a Rendu. 

[The Computer Audiophile]

1 minute ago, jiminlogansquare said:

DSD256 definitely eliminates the problem identified at DSD512. No dropouts/gaps in playback at DSD256. However, I want to run at DSD512 if possible, as this delivers - subjectively, to my ears, in my room and with my music sources - better sound from my T+A DAC 8 DSD. So, I have gone ahead and ordered the switch Chris recommends and try flow control for the Rendu to see whether that allows DSD512 without the glitches.

 

And on preview, I see you agree with Chris’s recommendation. I will report back here after I have implemented it. 
 

One other question, should I implement flow control only for the port assigned to the Rendu, or all the ports I am using (one copper port to hook the switch to the network, two fiber ports to hook the sonicTransporter and Rendu to the network)?

I would just enable flow control on the switch rather than get port specific. 

[The Computer Audiophile]

11 minutes ago, sdolezalek said:

I've been struggling with this dropout issue for several months at DSD512.  Miska was kind enough to forward me his Cisco switch settings (including the flow control setting he has copied above).   All of that helped, as did switching to a Gigabit cable modem and a better router, but it turns out that what was ultimately causing my dropouts was the data send pattern on Nest video cameras that were on a different switch and different LAN, but they caused just enough congestion at the modem to cause dropouts.  Having more throughput only caused the cameras to send in shorter higher volume bursts. Turning them off when I listed to music magically solved the problem... :-)  

 

I mention this only because, my lesson was that there are so many variables at work, not to imply that my solution has direct relevance to the OP's problem. 

Thanks for the information. It's truly the Wild West. Even though networking isn't rocket science, and the standards have been in use for seemingly ever, there are things that just happen and strange things that work how "nobody" would think they work.

 

The more sharing of information like this, the better off we all are. I have 12 Nest cameras, 3 smoke detectors, and one thermostat. I haven't had this issue, but the knowledge is now in my back pocket for future use. 

[The Computer Audiophile]

Here's how I would do it. 

 

Internet > Modem / Router > Copper Ethernet > New Switch 

 

New Switch > fiber > sonicTransporter

New Switch >  fiber > opticalRendu Lite

[The Computer Audiophile]

18 minutes ago, jiminlogansquare said:

One more observation. By using a copper Ethernet cable to attach the SonicTransporter to one of the copper ports on the switch, I got Roon to reconnect and work. I can access the SonicTransporter and Rendu via the sonicorbiter web interface now.  Moreover, the sonicTransporter will output to the opticalRendu via switch/fiber in this configuration - i.e., with the Rendu connected to the switch via fiber, and the sonicTransporter connected to the switch both by fiber and copper, and with the router connected to the switch via copper.
 

I still, however, cannot access the switch GUI as described above. So I cannot get to the controls to turn on Flow Control. 

Ok, there are a few things going on here. 
 

The Transporter could just be sending everything out via copper. 
 

The Transporter may need a config change to enable the fiber interface to get a DHCP address from your router. 
 

you don’t want the Transporter connected to anything with both connections. 
 

The switch may be getting a dhcp address from your router, in this case it’s default won’t be what’s in the manual. 
 

If it’s ip is still what’s in the manual, connect a computer to the switch, set the computer’s IP address to 192.168.0.2, then you can access the switch at http://192.168.0.1 and set it for dhcp rather than static. 
 

The default address for the switch should just be a fall back address if it can’t get dhcp. My guess is the switch has another ip on your network. 
 

let me know. I’m here to help. 

[The Computer Audiophile]

47 minutes ago, jiminlogansquare said:

A follow up. The new SFPs arrived but did not offer the hoped-for fix. After some more time testing various configurations with me, @plisskendetermined my new switch might be problematic. We were having difficulty getting it configured, including attempts to do a factory reset that were confounding. So, it was decided that a new switch is in the cards, and one is on order. More to follow, hopefully in the next week. In the meantime, I don't want to exaggerate the problem or create false negative impressions; the dropouts are a minor annoyance at most, and they don't impair the excellent SQ from the T+A DAC 8 DSD and opticalRendu. But a fix will increase my enjoyment, and with a little further assistance from @The Computer Audiophileand @plissken, I expect to get that fix soon enough. Stay tuned!

Hats off to @plissken on this one for putting so much time in. 
 

I agree we shouldn’t make a mountain out of a mole hill, but there also shouldn’t be any dropouts at anytime. We’ll get there on this one.