![sin xtr hqplayer sin xtr hqplayer](https://roon-community-uploads.s3.amazonaws.com/original/3X/e/3/e3e927acb43e9cb2c982baf80a829b68633b517e.jpeg)
Long may it last and hopefully this long post may help others who have issues. Well touch wood as we say in these parts but still no warbling - a perfectly solid sound from HQP to ultraRendu. 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… I blew some dust off a TP-Link 10/100 switch I had and put it in the chain.
![sin xtr hqplayer sin xtr hqplayer](https://3.bp.blogspot.com/-Wv09naHxVrI/XF9ks7PTe4I/AAAAAAAASY8/taNPLrmzmFshFWp9bAe1An9LPAwLrqYRwCLcBGAs/s1600/JRiver%2B24%2B%2B%2BpiCorePlayer%2BDFCs.png)
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).Ĭould a practical (and not too expensive) recommendation to test this be for to test a 100Mbps un-managed switch, right before the Rendu? But still the source computer may also have impact on the traffic patterns, depending on CPU load and Ethernet driver. 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. I have at least one machine with similar Killer Ethernet, just don’t remember right now which ones. 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. If you think those you’ve mentioned work better, then maybe it is better to use those instead on Rendu. And never had issues on any of the x86 based devices (various Atom/Pentium-based boards).
![sin xtr hqplayer sin xtr hqplayer](https://roon-community-uploads.s3.amazonaws.com/optimized/3X/5/d/5dff67433f10e61f1f2d86d72941d535f5248d12_2_386x500.png)
For me, things are working with microRendu, also on CuBox-i4Pro.
Sin xtr hqplayer software#
I don’t think I can help much more on the networkaudiod software module side. Jussi, Roon with RoonReady, LMS with SqueezeLite, and A+ with upmpdci/MPD have no issues. When the problem appears, there’s wavy fluctuation of the transfer speed up and down (transfer stalls).
Sin xtr hqplayer download#
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. However, there can be various reasons why this flow control doesn’t work… 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. This packet loss in turn causes retransmission which in turn makes things worse.
Sin xtr hqplayer full#
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. Since this is related to internal local bus bandwidth of the SoC, other things also affect it like USB traffic and such. The actual problem is at hardware and kernel level, but whether it is triggered depends on traffic patterns. It depends on the traffic pattern coming out of player - size/frequency of data blocks transmitted, etc. So again how can the Rendu be anymore or less overwhelmed playing one DSD512 stream to another DSD512 stream?
![sin xtr hqplayer sin xtr hqplayer](https://q4n3x6h5.stackpathcdn.com/wp-content/uploads/2021/03/hms-vs-hqp2.jpg)
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.