Hey John @Sloop_John_B
Since this issue came up, does it only happen at DSD512?
Or also with DSD256? Of course I’m not hinting to use a lower sample rate permanently - just for trouble shooting purposes obviously.
Cheers
I haven’t tried, I can if @jussi_laako asks.
At the moment (aren’t days off great?) I’m listening to a playlist that I use to test changes in equipment/ cables etc. to test the NAA/NUC using Jussi’s USB image. They are songs I know intimately, what sounds good in them, what can be irritating etc. I may just have to bite the bullet and make a decision, I just want to get back to listening to music not my system. All this faffing is going on just a little bit too long for me.
.sjb
1 Like
Hang in there John!
Jussi is the man.
Just to be clear and transparent, there are four factors in play here; 1) the networkaudiod (NAA) software module, 2) the OS running NAA, 3) the hardware this entire thing runs on and 4) the DAC. I always deliver (1), with my bootable images I also deliver (2) and can be considered a “reference build”. So far I never ship (3) or (4).
So at best, I have control over (1) and (2). Never over (3) or (4) although sometimes I can recommend something. To some extent, I can do things differently in (1), in regards to (2) and (3). Within limits of course.
If there’s a problem that doesn’t span all variants (for example my images), in order to try to do something about it in (1) I need to be able to reproduce it with all aspects combined.
I have microRendu and Holo Spring DAC, so I can try to reproduce problem with microRendu and Spring’s built-in USB. But I cannot promise to be able to make it work by modifying (1). But I cannot test with something like Singxer SU-1.
2 Likes
The issue occurs both with and without the Singxer in the chain so that isn’t the issue.
I appreciate the needle in the haystack aspects of my problem and also the fact that others don’t seem to have it adds to the difficulty.
I didn’t have the issue in the NAA/ultraRendu iteration that caused pops. So whatever fixed this most likely caused the new issue. I never had the pops with the NAA image running on a Windows machine and as mentioned above don’t have the drop-outs with this either.
It does seem to be an interaction between the NAA/ultraRendu and my PC that causes drop-outs. But as the screenshots show above it’s not that the machine is doing too much that is causing the drops but an apparent “micro-stop” in processing.
I do appreciate any help you can offer and let me know if I can test anything else to help you.
.sjb
One possibility is networking issue, but I cannot remember what kind of network setup you had…
I know there is more in heaven and earth than is dreamt of in my philosophy but I fail to see how the network can be an issue as it’s 100% the same network to the NUC.
A touch of the Fr. Jack’s “ecumenical matters” perhaps.
Anyway we were discussing networks here.
.sjb
That is precisely indication of such possible problem… Those small ARM devices get easily overwhelmed with I/O when there’s some more pressure simultaneously on different interfaces like network and USB. The SoC in Rendus can handle max 400 Mbps (theoretical) while the NUC has no trouble keeping up with 1 Gbps and doing other stuff at the same time. And that Killer Ethernet is designed to be able to really bang the gigabit network, it may be almost able to “kill” the Rendu 
.
I would have thought that if the Rendu was the issue Roon upsampling to DSD512 would have trouble also?
Anyway it looks like my choice is use the ultraRendu as Roon endpoint or NUC as NAA. I’m getting one of these to try
and then I can see what gives me the best sound.
.sjb
I’m confused. The Rendu has no issue playing DSD512 with Roon or your -2s filters for that matter…so how can it be under more pressure with your non-2s ploy-sine-xtr filters which are applied on the server? DSD512 is DSD512 and we are not doing any kind of additional processing before we output out to the DAC. So again how can the Rendu be anymore or less overwhelmed playing one DSD512 stream to another DSD512 stream?
It depends on the traffic pattern coming out of player - size/frequency of data blocks transmitted, etc.
The actual problem is at hardware and kernel level, but whether it is triggered depends on traffic patterns. Since this is related to internal local bus bandwidth of the SoC, other things also affect it like USB traffic and such.
When there’s a big enough data burst coming in, it causes packet loss at the receiving side because it cannot handle the amount of data coming in at full speed. This packet loss in turn causes retransmission which in turn makes things worse. Hardware level flow control implemented inside the network interfaces is quick enough to react to such situations and stops the packet flow before things get bad - this keeps the problem from appearing. However, there can be various reasons why this flow control doesn’t work…
This kind of issue can be reproduced also with large HTTP download (from gigabit server), or by sending a large file over FTP or SCP to the slower device and observing transfer speed during the transfer. When the problem appears, there’s wavy fluctuation of the transfer speed up and down (transfer stalls).
Could a practical (and not too expensive) recommendation to test this be for @Sloop_John_B to test a 100Mbps un-managed switch, right before the Rendu?
I’ve had both a NetGear FS108 and Cisco SG100D-8 V2 working well with Rendu’s and these can be found on eBay for cheap.
Jussi, Roon with RoonReady, LMS with SqueezeLite, and A+ with upmpdci/MPD have no issues. Let me know what you need from us.
I don’t think I can help much more on the networkaudiod software module side. For me, things are working with microRendu, also on CuBox-i4Pro. And never had issues on any of the x86 based devices (various Atom/Pentium-based boards).
If you think those you’ve mentioned work better, then maybe it is better to use those instead on Rendu. Although I’m not sure how widely your user base uses the ones you’ve mentioned at DSD512 (including 48k-base DSD512) 100% of their use time, so maybe it is not statistically very significant comparison base.
I have at least one machine with similar Killer Ethernet, just don’t remember right now which ones. Maybe it was the 10-core beast. I can try at some point from that to microRendu, but then it has three switches on the way which may make any possible difference disappear. But still the source computer may also have impact on the traffic patterns, depending on CPU load and Ethernet driver. Especially given something like hard-core Killer Ethernet which offloads almost all networking stuff to a separate networking processor (designed for low-latency network gaming use cases).
I know it can be difficult if your not seeing the issue on your end. This has nothing to do with what I think works better because my USB DAC doesn’t support DSD512:) Those protocols support different audio buffers or have a large buffer to start with.
NAA has a large FIFO. And HQPlayer has adjustment for “Buffer time” (which is separate from the FIFO size), but changing it from the default size with NAA usually don’t make things better…
Okay @jussi_laako my logic being that if there is a network issue, Roon upsampling to DSD 512 should show some similar instability, so I’ve run Roon exclusively upsampling for a week and Roon -> ultraRendu shows none of the instability that HQP -> ultraRendu manifests.
But I’ve reread your last posts and see you have addressed this.
@Jesus_Rodriguez is there any chance I have some instability within the ultraRendu as it rarely changes from HQP to Roon seamlessly, I usually get a cannot reach page error and when I go back into via the index page something like this shows up ( after this switching works fine).
Also I never had this issue with software version 2.5. (Although I appreciate correlation doesn’t imply causation) so is there any way to revert back to 2.5 to check this ?
I don’t mind purchasing an SD card if this is the only way to achieve this.
I’d really like to solve this puzzle.
.sjb
Just to go full circle with this and let you all know what I’ve been up to!
Well first off I purchased a Ciunas iso-hub on the 30day sale or return policy they run.
I put it in the chain as follows NUC->Ciunas ISO-HUB->Singxer->HoloAudio DAC and certainly i now had a sound I could live with, not the same as the ultraRendu in the chain but clearly better with than without and the treble glare had been dissipated.
And the story may have ended there except that I decided to try @dabassgoesboomboom suggestion.
I blew some dust off a TP-Link 10/100 switch I had and put it in the chain. A few hours went by without any warbling but hey one swallow never made the summer so I’ve been listening through the ultraRendu for about a week now and guess what…
Well touch wood as we say in these parts but still no warbling - a perfectly solid sound from HQP to ultraRendu. Long may it last and hopefully this long post may help others who have issues.
So in summary now all HQP filters except poly-sic-xtr work with my PC.
I’m hoping @jussi_laako who hinted that he had an idea why this filter wouldn’t play with CUDA fully enabled, will test his hypothesis in a future upgrade.
At the moment poly-sinc-mp is my favoured filter and I sometimes try the non-apodising ones if I think the music should sound better. I then tag these in Roon. as you can see Telekon sounds better in my system with minringFIR
Thanks especially @dabassgoesboomboom .
.sjb
1 Like
Happy days indeed John!
Now that it’s all working nicely after this epic battle… Don’t…Touch… Anything… 
That’s coming from someone (me) that regularly break things that are working fine.
Fantastic news.
2 Likes
YAY Telekon. Seeing Numan twice more this year, in DC and in Vancouver.
1 Like