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? 

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

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

[jiminlogansquare]

9 minutes ago, The Computer Audiophile said:

This isn't rocket science. 

Also not one of my strong suits.

[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)?

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

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

[jiminlogansquare]

Chris, check your PM. Thanks.

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

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

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

[jiminlogansquare]

25 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 

 

Thanks for the idea (and the warning). I actually am finding ASDM7 without EC, at DSD512, to sound better than ASDM7EC at DSD256. The dropouts with the latter are infrequent enough that I was able to give it a thorough listen, and I found that things like piano and violin just come through more true sounding, and the overall presentation has more air and energy around the instruments. But of course, YMMV. My ears, my system, and my unconscious bias after spending 100 hours trying to get DSD512 to work because I have read so frequently that my DAC plays its very best with that format and rate.