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? 

[plissken]

1 minute ago, Miska said:

 

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

 

 

I understand but the app dev is relying on the end user setting up flow control or knowing what that is. This is a buffer and not speed issue from my read.

 

What I don't understand is how Sonore advertises DSD512 support with out an * carve out. I didn't see anything about flow control in the online manual shouldn't this be a default on the OS?

[Miska]

32 minutes ago, plissken said:

I understand but the app dev is relying on the end user setting up flow control or knowing what that is.

 

Flow control auto-negotiation is enabled by default on most NICs and OS I've seen so far. It is also supported by most unmanaged switches.

 

Only notable problem are smart switches where the default setting varies. If it is disabled, the smart switch will just discard received pause frames without taking any action. This is what causes the trouble.

 

Another trouble are for example some copper-optical media converters that don't pass through the flow control auto-negotiation.

 

32 minutes ago, plissken said:

This is a buffer and not speed issue from my read.

 

Which buffer are you talking about? Overflow happens in NIC's hardware packet buffer. 1500 byte MTU's arrive pretty fast at 1 Gbps speed, so there's not much time from hardware buffer reaching high level to the time when you need to send out pause frame. This is why NICs handle this, because on modern OS and NIC you (luckily) don't even get interrupt for every received ethernet MTU.

 

Since this is about ethernet MTU level thing, correct layer for it is where ethernet MTUs are dealt with.

 

32 minutes ago, plissken said:

I didn't see anything about flow control in the online manual shouldn't this be a default on the OS?

 

For example on my Xeon workstation with Intel NIC:

~> sudo ethtool -a eno1
Pause parameters for eno1:
Autonegotiate:	on
RX:		on
TX:		on

 

It is default in most NIC drivers, including i.MX6 drivers. Problem are switches and "(audiophile) ethernet gadgets" that make this part fail.

 

[Miska]

On my Cisco SG350 switch series I now have for all ports:

 

On a HPE switch it is simpler:

[plissken]

35 minutes ago, Miska said:

Which buffer are you talking about? Overflow happens in NIC's hardware packet buffer. 1500 byte MTU's arrive pretty fast at 1 Gbps speed, so there's not much time from hardware buffer reaching high level to the time when you need to send out pause frame. This is why NICs handle this, because on modern OS and NIC you (luckily) don't even get interrupt for every received ethernet MTU.

This is what I'm wondering about. I would hope that the application layer as it's own buffer and can keep NIC FIFO from over filling.

 

It circles back to Chris's thread about buffering and I posed the question about how data streams should be handled at the application layer. I use JRiver and can buffer entire albums in seconds with 10GBe.

[Miska]

6 minutes ago, plissken said:

This is what I'm wondering about. I would hope that the application layer as it's own buffer and can keep NIC FIFO from over filling.

 

Of course it has, but it of course doesn't help on this. This is overall average transfer speed issue. You will hit it with any protocol like HTTP, FTP, etc. Resulting in unstable transfer speed because of the stalls and the average transfer speed falling way below the possible.

 

With about 60% average packet loss without flow control it is kind of stupid and futile use of network resources and goes against the goals of for example NAA. Instead of trying to work around huge packet loss with dirty hacks, I want it clearly exposed and fixed properly.

 

[sdolezalek]

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. 

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

[jiminlogansquare]

Follow-up while I wait for delivery of the managed switch Chris recommended (let's call this the "New Switch").

 

Currently, the sonicTransporter is connected via a 30-foot run of CAT6A to an unmanaged switch (TP-Link TL-SG105) in an office, remote from my listening room (let's call this the "Office Switch"). My office PC and household Google Home WiFi router are also plugged into the Office Switch.

 

If I follow Chris's recommendation, I would be placing the New Switch in my listening room, detaching the listening room end of the CAT6A from the SonicTransporter and attaching it to the New Switch, which would as a result be connected to the Office Router via the CAT6A run. I would then use fiber to attach both the sonicTransporter and the opticalRendu to the New Switch. Finally, I would set Flow Control "on" for the New Switch.

 

So, (1) am I properly describing what I should do, and (2) is there any chance of unintended negative consequences from attaching the New Switch to the network through the Old Switch in this way? If as Chris says networked audio is still the Wild West, I want to make sure my six-shooter isn't jammed. Thanks again, all!

[jiminlogansquare]

Adding this here because the edit window has closed, I figured out a way that I can remove the Office Switch completely from my network. I can connect the 30-foot run of CAT6A at the office end directly to the Google Home router and attach the other end to the sonicTransporter in the listening room. My office PC works fine over WiFi, so the Office Switch is actually unnecessary.

 

I am testing that configuration as I type this, and it works the same as with the Office Switch (dropouts and all). Presumably this will also work with the New Switch in the listening room (without the dropouts, fingers crossed!). But please confirm from my previous post and this one that I am getting this right; thanks.

[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

[jiminlogansquare]

OK, @The Computer Audiophilethe switch arrived. I have installed it as you recommend. However, I am having issues getting it to work. Can you assist?

 

I have the router connected via copper Ethernet plugged into port 1 of the switch and my PC in another copper Ethernet port. Note that my PC works fine hooked to the switch in this way.

 

When attempt to access the GUI of the switch by typing the default management address (http://192.168.0.1) into a browser on the networked PC, I get a "connection timed out" error. The instructions that accompany the switch tell me to see Appendix B of the User Guide for more details. However, there is no Appendix B in the User Guide.
 

In case this helps, I am unable to access Roon with the switch in the network. Also, I am unable to manage sonicTransporter and opticalRendu using the Sonicorbiter web interface (this allows ones out).

[jiminlogansquare]

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. 

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

[jiminlogansquare]

Chris, check your PM. Thanks.

[vortecjr]

The Rendu sends a flow control request on boot to the connected device (server, router, switch, etc.). The current version of SonicOrbiter v2.8 is required. 

 

My understanding is that your DAC is based on an Amenero USB interface. The firmware that interface uses will more likely than not dictate the highest sample rates you can stream and how nice it plays with Linux. There is a post on the SonicOrbiter Forum under Sonore Product Support that has more information. 

[plissken]

I wanted to add some color to this as I did a T-shooting session with Chris and Jim. The data showed that the Rendu, on either SFP port is flapping non-stop.

 

Jim said the SFP was loose and prone to coming out if touched on the Rendu side. Even when the SFP module was reinserted with a bit more force the flapping didn't permanently go away. When it did stay stable it was ping-able and it could be reached by web browser.

 

Jim ordered four replacement SFP's from FS.COM and we will try again.

 

All this brings me to my last point: If you are getting a switch with SFP modules please check with the manufacturer that it has a CLI in addition to the Web Interface. It makes troubleshooting much easier. Even though I wasn't familiar with TP-Links CLI I was able to orient myself in a few minutes and provide diagnostic value. It's clunky as hell but better than nothing :-)

[jiminlogansquare]

@vortecjr, my Rendu has sonic orbiter v2.8; see below. Also, I know all about the Amanero USB input! It took a lot of effort, but I was able to update its firmware to a stable upgraded version (2006be 11) that generally plays well with Linux, and is supposed to work at rates up to DSD512. Other than the occasional dropout that inspired me to start this thread, DSD512 was working well and sounding great through the Rendu and T+A DAC 8! That said, I agree that the Amanero board is not a good match for Linux (and T+A definitely agrees; they try to accommodate Linux but clearly and expressly designed the DAC 8 DSD for Windows PCs).

 

@plisskenand @The Computer Audiophile were extremely gracious and generous with their time to (1) propose a remedy involving adding a managed switch with Flow Control in the relevant ports, and (2) spend several hours(!) online getting the switch configured and working through the “flapping SFP” issue described by @plissken. The “loose fit” of the SFP in the Rendu appears to be my clumsy hands and not a problem with the Rendu. Moreover and coincidentally, it does look like one of my four SFP modules was defective or damaged by my fumbling around, and the hope is that getting new SFP modules in place (one each at the Rendu and sonicTransporter, and two in the fiber ports of the switch) will solve that issue. @plissken has configured the switch so the relevant ports have Flow Control turned on. Hopefully this will fix the dropouts. I should know by tomorrow, when the new SFP modules are set to arrive. 

[fmzip]

Stumbled across this thread trying to find a solution to a similar problem.

 

My setup was an SGC I5 but wanted to upsample 44K to DSD512. The i5 wasn't up to the task so I bought an Intel NUC8i7BEH installed ROCK for ROON. Figuring this was as good as a Nucleus+, thought I'd be good to go.

 

At first I was able to play 44k>dsd512, then I started experiencing dropouts. Some items in the pipeline, Sonore UtlraDigital & Ultra Rendu. I'll post my findings as well by moving the NUC to the same switch as the rest. I'l try swapping out my Asus RC68u Router to the Unifi Dream Machine too. Interesting how those Nest cameras messed with the setup. Maybe a managed Router like the dream machine would isolate traffic better  instead of having to shut things off..

 

Gremlins....hate them! 

[jiminlogansquare]

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!

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

[plissken]

12 hours ago, The Computer Audiophile said:

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. 

 

Another potential solution is to setup rate limiting on the port to 80% of the end point's 400Mbit capacity.

[asdf1000]

On 1/28/2021 at 9:43 PM, vortecjr said:

The Rendu sends a flow control request on boot to the connected device (server, router, switch, etc.). The current version of SonicOrbiter v2.8 is required. 

 

My understanding is that your DAC is based on an Amenero USB interface. The firmware that interface uses will more likely than not dictate the highest sample rates you can stream and how nice it plays with Linux. There is a post on the SonicOrbiter Forum under Sonore Product Support that has more information. 

 

This current DSD512 issue is only a problem for opticalRendu right?

 

microRendu and ultraRendu are not affected?

 

[jiminlogansquare]

I wanted to revive this thread first to publicly thank @The Computer Audiophile and @plissken for spending literally HOURS and HOURS, including a couple of late nights, troubleshooting this for me. Their generosity and support of a forum member in need deserves recognition. Proof, if I needed it, that this forum is both run by and attracts a great group of people.

 

Second, I wanted to let those who are interested know that ultimately I solved this problem, by moving to HQPlayer with Roon for upsampling to DSD512. Apparently the problem may have had at least something to do with Roon's internal upsampling and/or its DSD modulation.

 

Maybe HQPlayer's algorithms are more efficient and don't overwhelm my CPU. Without question, HQPlayer offers myriad more options for filters and modulation to fine tune the process, some of which run well, several of which stop my sonicTransporter's processor dead in its tracks, and others of which trip it up sporadically and at least as much as what I report above with Roon. Some in particular won't work at all with DSD512 (especially the "EC" modulators, which are a heavy lift even for DSD256 .... a phenomenon that's well documented in the various threads here devoted to HQPlayer).

 

But bottom line, after finding an appropriate set of filters and modulation in HQPlayer, I have been upsampling Qobuz streaming files to DSD512, with the original files at all bitrates from from 44kHz to 192kHz, and outputting it to my T+A DAC 8 DSD via opticalRendu, flawlessly for hours on end, with no dropouts, and with wonderful sound quality, to boot.

 

For the curious, in HQPlayer I settled on the poly-sinc-ext2 filter at 1x and Nx rates, ASDM7 modulator (not EC, which strained my SonicTransporter i9 CPU and led to dropouts even at DSD256), and upsampling to DSD512. This combo so far gives what I find to be the best or most pleasing SQ for me, and with zero dropouts. I am sold on HQPlayer based on this.

 

That all said, there is one potential confounding factor I haven't mentioned, and that is that in order to use HQPlayer, I had to upgrade my opticalRendu Lite, which only handled Roon, to a "full service" opticalRendu, which works as an NAA for HQPlayer.  It is certainly possible that there is a significant difference between the two Rendus that could account for the phenomena I describe above. I can't really control for that, however; one change to my system (adding HQPlayer) required the other change (upgrading the Rendu). But there you have it. I am happy with the results and wish I had gone this route in the first instance.

[Account Closed]

40 minutes ago, jiminlogansquare said:

I wanted to revive this thread first to publicly thank @The Computer Audiophile and @plissken for spending literally HOURS and HOURS, including a couple of late nights, troubleshooting this for me. Their generosity and support of a forum member in need deserves recognition. Proof, if I needed it, that this forum is both run by and attracts a great group of people.

 

Second, I wanted to let those who are interested know that ultimately I solved this problem, by moving to HQPlayer with Roon for upsampling to DSD512. Apparently the problem may have had at least something to do with Roon's internal upsampling and/or its DSD modulation.

 

Maybe HQPlayer's algorithms are more efficient and don't overwhelm my CPU. Without question, HQPlayer offers myriad more options for filters and modulation to fine tune the process, some of which run well, several of which stop my sonicTransporter's processor dead in its tracks, and others of which trip it up sporadically and at least as much as what I report above with Roon. Some in particular won't work at all with DSD512 (especially the "EC" modulators, which are a heavy lift even for DSD256 .... a phenomenon that's well documented in the various threads here devoted to HQPlayer).

 

But bottom line, after finding an appropriate set of filters and modulation in HQPlayer, I have been upsampling Qobuz streaming files to DSD512, with the original files at all bitrates from from 44kHz to 192kHz, and outputting it to my T+A DAC 8 DSD via opticalRendu, flawlessly for hours on end, with no dropouts, and with wonderful sound quality, to boot.

 

For the curious, in HQPlayer I settled on the poly-sinc-ext2 filter at 1x and Nx rates, ASDM7 modulator (not EC, which strained my SonicTransporter i9 CPU and led to dropouts even at DSD256), and upsampling to DSD512. This combo so far gives what I find to be the best or most pleasing SQ for me, and with zero dropouts. I am sold on HQPlayer based on this.

 

That all said, there is one potential confounding factor I haven't mentioned, and that is that in order to use HQPlayer, I had to upgrade my opticalRendu Lite, which only handled Roon, to a "full service" opticalRendu, which works as an NAA for HQPlayer.  It is certainly possible that there is a significant difference between the two Rendus that could account for the phenomena I describe above. I can't really control for that, however; one change to my system (adding HQPlayer) required the other change (upgrading the Rendu). But there you have it. I am happy with the results and wish I had gone this route in the first instance.

Jim, If you can put a monitor on the ST i9 and look at the BIOS at boot up you may find that there is some unused processing power available. You may be able to use ASDM7EC/256 modulation with some BIOS adjustment. I can get ASDM7EC/256 and Closed Form Fast as the filter with my i5 8400 in a passively cooled case similar to what Andrew uses for the ST i9. I don't know what Mother Board Andrew uses so you would have to do some research to see if there is anything you can try. That said, be careful and do not be aggressive. It is possible to go too far and damage the CPU but with modern MBs it is not likely as they usually won't boot if the settings are pushed. I have an ASUS Z370i MB and ASUS BIOS is well documented and easy to work with. You could check with Andrew first to see if he can help but he will likely say no and tell you that your warranty is invalidated if you try.

 

Anyway, just a thought and BTW I love the Finisar SFPs I bought from you a while back.

 

Glad to hear that you got your setup working. I had followed this thread with interest.

 

Bob 

 

[Account Closed]

8 minutes ago, bobflood said:

Jim, If you can put a monitor on the ST i9 and look at the BIOS at boot up you may find that there is some unused processing power available. You may be able to use ASDM7EC/256 modulation with some BIOS adjustment. I can get ASDM7EC/256 and Closed Form Fast as the filter with my i5 8400 in a passively cooled case similar to what Andrew uses for the ST i9. I don't know what Mother Board Andrew uses so you would have to do some research to see if there is anything you can try. That said, be careful and do not be aggressive. It is possible to go too far and damage the CPU but with modern MBs it is not likely as they usually won't boot if the settings are pushed. I have an ASUS Z370i MB and ASUS BIOS is well documented and easy to work with. You could check with Andrew first to see if he can help but he will likely say no and tell you that your warranty is invalidated if you try.

 

Anyway, just a thought and BTW I love the Finisar SFPs I bought from you a while back.

 

Glad to hear that you got your setup working. I had followed this thread with interest.

 

Bob 

 

OOPS, I think I purchased a USB Regen from you. I love that as well.