That’s certainly what I’m finding.
.sjb
Unfortunately, If you guys are using beta firmware you can almost certainly expect these kinds of issues with your DAC.
I would really love to stop using beta fw. I would Amanero has burnt a lot of bridges with dac makers.
I’m not using beta firmware, but then others with similar systems are not experiencing similar issues. Frustrating this hobby sometimes!
.sjb
DSD512 solutions are experimental IMO. There is a reason why most DACs stay away from it. DSD256 is really the sweet spot.
1 Like
I’m just curious what kind of network connection people who have problems are using?
Because if ethernet flowcontrol (802.3x) is not working, one can expect all kinds of strange issues with low power NAA devices…
OK but why no issues using WIN ASIO drivers ?
Something different and more difficult to tune on USB receivers firmware regarding ALSA (LINUX) ?
Different firmware version and different way to transfer raw DSD…
I have never a/b’ed 256 v. 512, but have with 128 v 512. Huge improvement in sq. Why do you say 256 is the sweetspot? Does 512 inject problems other than the processing issues?
Any ideas on solving my issues considering that everything worked fine before I updated HQP and MR sw?
Thanks for the input.
So far, I’ve been playing all formats, including DSD512 without issues. Some of my smallest NAA hardware cannot handle DSD512, but that’s just limitation of those pieces of hardware.
By the way, it is actually really hard to compare “Win ASIO drivers” vs something completely different. How similar was your Windows-based NAA installation and network connection compared to this one?
Some more powerful Windows machines don’t necessarily need the 802.3x flow control in first place. They can hide the issue with sheer I/O capacity. It doesn’t mean problem doesn’t exist, it just doesn’t become as visible.
Understood and i agree.
I was mostly talking about Amanero FW, lot of users have issues or glitches on Linux, less or no complaints on WIN ASIO. Network flow control, HW, SW, FW … lots of variable !
Yes, the ones that work on Linux with native DSD should be considered beta-quality. The older one that is used in T+A DAC8 DSD and the likes works fine on Windows through ASIO driver, but naturally doesn’t work higher than DSD128 on Linux through DoP…
But if network source/software makes difference, it would rather indicate networking problem. Because the driver and firmware are the same for all. Of course it still could have something to do with the driver too, because Linux allows pretty low level access and lot of configuration variables / usage scenarios. But I just see it more likely to be network related if different software works in different ways.
1 Like
@jussi_laako, @Jesus_Rodriguez
So, I tried playing 256 with HQP and it worked for about an hour and then the hiss/buzz came back. Roon dsp still working fine.
Given that, I think we can rule out CPU issue (although I never though that was the issue given that I have an i7 server purpose built to play HQP). While I know te Amanero beta is not the best, I also doubt that is the cause given past performance and the fact that I can play 512 with Roon dsp w/o issue.
Any ideas on cause? An,d solution?
Thanks for the time and input.
Are you using a NAA? If you are, can you try without, using a direct USB connection? In earlier comment regarding CPU I was referring to CPU power of the NAA, not the HQPlayer machine.
As I said before, I consider it likely that it is a network issue. I know Roon is using a workaround in order to try to work around the problem. But the problem has adverse effect in any case even with that workaround. I don’t want to attempt to hide the problem by applying such workaround, such the difference between Roon and HQPlayer.
Another possibility is still CPU load of your HQPlayer machine. Depending on your HQPlayer settings, it is likely much heavier on CPU than Roon, to DSD512. So you cannot really compare and say if Roon can do DSD512 on machine X, HQPlayer would also do (with any settings). This is certainly not the case. Using direct connection instead of NAA would tell if this is the case… This helps reducing the number of variables and isolating the problem. Otherwise there are just so many possibilities that trying to solve it is shooting in the dark.
What exact information are you looking for here, sorry if I’m being dim?
.sjb
Sorry, but I don’t understand the question?
Okay I have a Virgin Hub 3.0 which provides internet. This is connected to a netgear 24 port switch
https://www.amazon.co.uk/NETGEAR-JGS524-200EUS-ProSAFE-24-Port-Ethernet/dp/B0027GUGDG
I have the ultraRendu connected directly to the Virgin Hub as recommended by Jesus or agillis as the ultraRendu was losing network visibility that required a reboot when connected to the netgear.
Roon and HQP run on a PC connected to the netgear.
is this the information you are looking for?
.sjb
That switch is fine, it has support for both 802.3x flow control and 802.3az energy efficient ethernet. The latter is just good extra for keeping network generated noise low. But I’m surprised microRendu had problems when connected to this switch which may be indicative of the root cause. It really should work fine when connected to the Netgear switch. And another question is immediately if the Virgin Hub honors 802.3x.
Then next thing to look at is if the network interface on your PC supports flow control and has it enabled. You could go to Control Panel / Device Manager, look up the network interface, right-click and select Properties. Then in the driver settings tab check if there’s an item called “flow control” or “802.3x” and what is it’s setting status.
1 Like
I will try to connect server directly to Dac although it will take a while in my setup.
The reason I do not think the issue is CPU of either my Mircrorendu or my server is (a) I had no issues prior to updating software on MR and HQP last week and (b) even 256 is glitch now (much less cpu demand than 512). I know that the Roon dsp is less demanding.
Thanks @jussi_laako, @Jesus_Rodriguez