Unless there was some difference in the DSP/MUSE configuration between the two cores.
Other than that, @Boris_Molodyi is correct, RAAT is carried over TCP/IP which guarantees bit perfect delivery unless the link breaks but does not make any temporal guarantees. Consequently, the RAAT packet will be delivered bit perfect in both cases.
If something were to occur on the network such that the RAAT packet was delayed by an amount more than the buffering in the ROON endpoint could accomodate - you would get audio dropouts which would be very audible - but that is not a subtle effect and is not likely to be confused with any percieved AQ differences.
I currently do not have a native DSD256 roon ready renderer here so I tried to do a similar experiment. Two DSD256 streams simultaneously DSP´ed and back to DSD128. That is definitely squeezing the last reserve out of my Celeron N5105! Processing speed goes as low as x1.5 and CPU is constantly over 50% usage getting seriously hot. But there is no additional RAM eaten up. None at all. That must be a side-effect of running out of CPU capacity.
Funnily I remember your AMD R1600 being a bit more reactive with roon´s frontend compared to the Celeron but on the long run when handling heavy streams the latter seems to have a bit more of reserves. I am pretty happy with it.
I run Roon in a Docker container on a RS1221+ (V1500B with 32GB). I don’t do anything with DSD but I do have a single DSD256 test track.
I turned on some Muse filters and played the track. Just fiddling on a Mac using Core Audio but you can see that there’s a DSD-> PCM conversion, additional conversions, etc.
There’s other stuff happening on the NAS so not all of the CPU consumption you see is Roon. I don’t know how to force the conversion back to PCM, so perhaps that accounts for the discrepancy we see, but my result seems very different from yours.
I think it is the conversion back to DSD that is very resource-intensive. EQ and convolutions are comparatively lightweight, and DSD to PCM is heavy but not terrible, but adding PCM to DSD lowered my processing speed to something like 0.1x.
Adding more RAM helped a bit nut still not enough.
I see that now - I don’t think I have a DSD256 capable device but my Naim Uniti Atom supports DSD128 and forcing Roon to convert to that caused its processing speed to drop below 1.0x.
I don’t see the memory usage you describe (I’m still in the low 2 digits) but if processing speed can’t keep pace, resource consumption doesn’t really matter.
I do have questions about the sensibility or benefits of DSD → PCM → DSD, but I’ll keep those to myself
I have a HiFi Rose that is capable of DSD512 (although interestingly, only DSD256 through Roon) so I thought I’d try it.
I think there are none whatsoever (or to DSD in general) but I do have a nice Carmina Burana recording that was recorded in DSD originally, and it looks like I have Roon configured to preserve original resolution after applying convolutions, so DSD-PCM-DSD it went.
I do have some DXD tracks (that’s what… 352.8/24) and those are processed by Synology wsithout breaking a sweat.
Given that the basic philsophy of DSD is that it doesn’t make sense to convert other formats to it (that its raison d’être is to be pure from end to end), I think this is an edge case that should probably not be a standard part of the “Average Roon Roger’s” consideration for Roon hardware choices…
I agree from a theoretical point of view…
but in practice…
I notice that there is a difference in SQ (sound quality) between a Nuc/Rock and a Synology/Core
question: which servers did you compare?
Nuc-Rock? Nuc-Windows? Nucleus? Synology-Nas? Mac?
Did you do a blind ABX test? If not, this is just psychoacoustics…
I’ve compared Roon Core running on a couple of different laptops (including ones connected on WiFi) and Synology. Nope, no SQ difference. Which could be psychoacoustiocs, too, but again, if there were any difference, whoever discovers it would be looking for a room to store all of his Nobels, as it would completely upend our understanding of rather basic physics (and math). Seeing as this is not happening…
Neither a Nucleus (even Roon does not claim that). They all send exactly same packets (assuming no DSP of course) over the network. Or from USB port as well.
Well, then saying that one sounds different from another is an extraordinary claim that requires and extraordinary proof. Something that has never been provided…
[quote=“Boris_Molodyi, post:35, topic:255557”]They all send exactly same packets …over the network
[/quote]
in my opinion, saying that “exactly the same packages” is the only dimension of the problem is also an extraordinary statement !
there are other dimensions such as the quality of the power supply (linear?), the electrical noise of the motherboard, the design of the OS (Rock, Windows, DSM,…), aso…
in the meantime, I imagine very well that there could be no difference between your laptop and your Nas (that’s not the comparison I made)
These certainly are things that sellers of audio snake oil would very much like you to believe make any difference, but as anyone involved with electronics would tell you, none of them, within reason (especially LPS), make any difference. And it’s not like Nucleus had any kind of special motherboard. OS design is the last thing that could affect anything at all, too…
Sure, if one piece of equipment blows smoke, sparks flying every which way, it probably will affect sound (and burn your house down).
It is interesting that people who want you to believe that irrelevant thing make a difference will put up tons of sciency-sounding explanations(LPS… OS design… CPU load… etc. etc.) but nobody will ever show either a measurement showing that there is any difference or a blind test result that shows anything at all.
I would love as much as anyone if there were some magic piece of gear, like a power supply, fuse, or some magic crystal that could improve the sound and lift veils with no work involved but alas, it does not exist.
Fortunately it isn’t an extraordinary statement. It’s fundamental. We rely on the factualness of @Boris_Molodyi’s assertion every time we send or receive an email, work on an online document, shop and purchase online, and even when we interact with this forum.
Imagine you sit in front of an electric typewriter, insert a sheet of paper, and type a series of 1’s and 0’s. You eject the sheet of paper, carry it across the room, and read it out loud. Assume that you don’t trip, and that you are capable of reading and pronouncing the 1’s and 0’s accurately.
The 1’s and 0’s are the 1’s and 0’s. If someone were to tell you that they’d somehow sound better or be different in some qualitative way if you changed the power supply on your typewriter, you would probably not take that claim seriously. If someone else claimed they’d be qualitatively better on the receiving end if you used a different brand typewriter, you’d probably also dispute that.
This digital stuff is deterministic. It’s not magical. For those of us that have deep and long experience in this domain there is, perhaps unfortunately, no mystery left here. We know how it works because, in some cases, we’ve designed, evolved, deployed, and worked with these specific technologies for a really, really long time. It’s just not a matter of opinion. But all of that never seems to stop or even slow down the debates about it all
If we wanted to get very nitpicky, we could say that some super-excessive noise in connections between components, or super-unstable power might theoretically have some effect on the sound in the equipment that is not well-designed. Good thing that anything that complies to appropriate standards and was designed not by Uncle Fraudy McFraud but someone with at least a high school understanding of physics, it is not an issue Whatever noise there might be in e.g. ethernet connectors (and ethernet signal is of course just a very high frequency noise in analog world). Fortunately, even off the shelf components take care of this quite easily.
One suspects that any such issues would be so severe as to stop the Roon core working period - in which case you could not claim that the issue was one of Audio Quality.
As many on this thread know, ethernet is a differential signalling system and does not rely upon absolute signal levels and, unless CAT 7 or above cabling is used, there is no ground or power connection between the two pieces of equipment so ground/power issues do not propagate (CAT 7 and above cables employ a 'shield; which is connected to the caseing on the ethernet connector however, even this does not guarantee an ground connection between the two connected devices). The signal noise carried by the ethernet cable is usually irrelevant because it is ‘common mode’ which means that it is rejected by the receiver - in exactly the same way as injecting an antiphase copy of audio noise cancels the noise in noise cancelling earphones/headphones.
In addition, if you consider the connection between a ROON core and an streamer, there is invariably an ethernet switch (either discreet or part of a router) between the two which receives each IP packet and then forwards (re-transmits) them to the streamer. This switch would naturally remove any excessive noise (or crash itself).
Of course, the streamer (or even the core - although that is not recommended) may be connected by WiFi. In that case the streamer is galvanically isolated from the core so electrical noise will not propagate from core to streamer.
