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

[jiminlogansquare]

I use Roon DSP to upsample Qobuz streaming PCM files to DSD 512, on top of a 66K taps Audiolense convolution filter. My server is a SonicTransporter i9 and my Roon output (endpoint) is an opticalRendu Lite (for Roon only).

 

This configuration works great about 95% of the time, with processing speeds around 2.7X, but occasionally I get dropouts (gaps in playback).

 

The dropouts can be infrequent, with an hour or more between instances. Or they can come in bunches of two or more in a single track. The first couple of seconds of a track sometimes also gets clipped off.
 

What are folks' thoughts on this? 

[topside3]

UPDATE - Got the new network switch as recommended in this thread - and enabled flow control. Drop outs are gone!! Thanks!

[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

 

 

[jiminlogansquare]

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.

[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. 

 

 

[jiminlogansquare]

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.

[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. 

[jiminlogansquare]

9 minutes ago, The Computer Audiophile said:

This isn't rocket science. 

Also not one of my strong suits.

[plissken]

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.

[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. 

[plissken]

1 minute ago, The Computer Audiophile said:

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

 

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

[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. 

[plissken]

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.

[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. 

[plissken]

11 minutes ago, The Computer Audiophile said:

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. 

 

I don't do DSD or high SRC rates so I don't know the data rates, and hence my suggestion of going to DSD 256 initially. It's my nod to that it could be a saturation issue.

 

It sound's like the Rendu has a 100/1000 PHY but not the bus behind it for full wire speed? That's odd for the given costs.

 

I would have to ask @Miska if he's using flow control and relying down layer in the OSI stack for a control mechanism so he doesn't have to make it happen in the session or application layer. Again just a guess on my part.

 

Your suggestion is a good one as it's certainly affordable to try.

 

 

[jiminlogansquare]

9 hours ago, plissken said:

 

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

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 will try flow control 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)?

[plissken]

What are your thoughts on just using a Raspberry Pi4 with Volumio to test with?

 

I know the GBe on it is full data rate.

[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. 

[plissken]

Just now, 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 - a 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)?

Glad to hear DSD 256 works.

 

You would enable Flow Control on all interfaces in the path.

[Miska]

1 hour 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.

 

No, it is not, problem is that for example the iMX6 SoC is capable of maximum 400 Mbps bandwidth (with 802.3x) and has 1 Gbps ethernet interface. This is documented in it's datasheet and erratas. Without flow control it's hardware packet buffer overflows, because the local bus between NIC and the CPU cannot pass more than 400 Mbps. Hardware buffer is not so many ethernet MTUs. The NIC itself is capable of generating pause frames to avoid this overflow.

 

This is not much different with many other low power ARM SoCs. If overflow happens, it triggers TCP re-sends which in turn makes the situation worse causing transfer stalls. Which doesn't work well for realtime audio streaming...

 

Sometimes 802.3x auto-negotiation doesn't pass media converters or such, even if technically enabled on the link for example from the switch. This depends on capabilities of the media converter or similar device on the path, since it is fairly low level operation.

 

Overall, looking at my switch statistics for pause frames, for example my iMac's and other switches and computers are also actively using pause frames. These are also used between my switches in a star-like topology. Because I can have for example five computers trying to write to a NAS at full speed, which is behind 1 Gbps intra-switch connection. So the computers could be pushing 5 Gbps worth of traffic that needs to squeeze through 1 Gbps link anyway.

 

When pause frames are not available (not negotiated), for example HPE switches support emulating this by generating artificial collisions on the link. However, this is less efficient way.

 

1 hour ago, plissken said:

It sound's like the Rendu has a 100/1000 PHY but not the bus behind it for full wire speed? That's odd for the given costs.

 

It has 1 Gbps PHY, but the bus behind is capable of max 400 Mbps. You can check out NXP's i.MX6 datasheet and errata about this, where they directly state that it can reach 400 Mbps when used with pause frames. Without flow control the speed varies a lot due to stalls. With flow control the performance is just fine, stable and works as expected.

 

[Kal Rubinson]

1 hour ago, plissken said:

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

Me, too.  I routinely run 6 channel DSD256 through my 1GBe links without any indigestion.

[Miska]

13 hours ago, The Computer Audiophile said:

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

 

AFAIK, sonicTransporter i9 has i9-9900, not the K-model.

 

[plissken]

2 hours ago, Miska said:

Hardware buffer is not so many ethernet MTUs. The NIC itself is capable of generating pause frames to avoid this overflow.

 

I was wondering about this as it's a common option directly on NIC's.

[plissken]

I understand this is a end point buffer issue (overflow) and that Flow Control is used to do this at layer 4 instead of handling it at layer 6 or 7 from a software developer point.

 

 

 

[Miska]

6 minutes ago, plissken said:

I understand this is a end point buffer issue (overflow) and that Flow Control is used to do this at layer 4 instead of handling it at layer 6 or 7 from a software developer point.

 

Since it's a hardware buffer overflow and the hardware buffer is not directly visible to the software, best place to deal with it is at the hardware level where there is also sufficient reaction time to the buffer situation. With high level software it would be always late and anyway just guesswork. Especially for stream type protocols like TCP (involving window sizes, etc).

 

So I see it as correctly dealing with the situation at the layer where it also happens... It also deals with it once and for all for all the higher level protocols.