The Computer Audiophile

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.

I just learned this and can't believe how talented Miles was. Stunning.

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

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.

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.

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

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.

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-Gig

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

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

I'm streaming now without any issues using Roon to resample to DSD512 and using a convolution filter with 66k taps from Audiolense. From a QNAP to an opticalRendu. no glitches. Perhaps, you want to discuss this issue in another thread, so we don't go too off topic in the HQP thread.

Hang on, I’ll test it.

It’s hard for me to believe an i9 system has trouble with Roon DSD512 and convolution. I can do this on an i5 QNAP NAS. I think something else is afoot. I’m willing to bet you’ve maxed out the oR Lite.

more details here: