A novel way to massively improve the SQ of computer audio streaming

[romaz]

22 hours ago, seeteeyou said:

And then the BEST part is an internal (lower impedance) Molex connector in addition to an external (higher impedance) DC connector, therefore it should be easier to try power cables with higher gauge number / lower resistance.

 

 

Whoa, thanks for bringing this up!  Larry and I had been discussing trying out the Intel NUC7i7DNBE board as a RoonServer:

 

https://www.intel.com/content/www/us/en/products/boards-kits/nuc/boards/nuc7i7dnbe.html

 

I actually selected this particular board purely because it is only 1 of 2 i7 NUC boards that Akasa is making a fanless chassis for at this time.  This is a commercial class NUC board and as you stated, it accepts 12-24V but what is more important to me and what I didn't realize until you brought it up is that this is one of only a few Intel NUC boards that can be powered via a 2x2 Molex connector which is a better alternative to the high impedance 5.5mm x 2.5mm barrel connectors that most NUCs and small audio endpoints use. 

 

22 hours ago, seeteeyou said:

NUC7i3DN and NUC7i5DN came with only 1.5MB cache per core, and we're still getting 2MB cache per core from NUC7i7DN.

 

This is not entirely accurate but the news is good.  The NUC7i3DN and NUC7i5DN you mentioned above actually incorporate 3MB of SmartCache.  Probably for cost reasons, most Celerons and budget CPUs incorporate L2 or L3 caches that are not SmartCaches which means the 4MB of cache used by the Celeron J4005 CPU in my NUC shares this cache evenly among its cores.  Since this is a 2-core Celeron, then each core gets 2MB of cache.  If only a single core is being utilized by an app, that core can only access 2MB of cache and not the entire 4MB. 

 

The advantage of Intel's SmartCache is the entire cache can be used by whichever cores are active and so with a single-threaded app that uses only a single core, that single core now has the potential of accessing the entire cache.  With the NUC7i3DN or NUC7i5DN, this means a single core can access the entire 3MB of cache and generally speaking, the larger the cache, the lower the CPU latency.  With the NUC7i7DNBE board I have been eyeing, the i7-8650U CPU that it utilizes has a very healthy 8MB of SmartCache!

 

What is further appealing with the NUC7i7DNBE board is that the CPU's TDP can be downrated to 10w just like my current Celeron NUC.  What I am hoping is that SpeedStep and Turbo can also be turned off through the BIOS.  If this is possible, this would allow me to very closely mimic the Celeron CPU in my NUC but with a much larger and smarter cache.  This would mean that this board could be well suited as both a RoonServer board and a RoonBridge board.  As a RoonServer board, as this board has the capacity for 32GB of RAM, it should be possible to store both the entire OS as well as the entire Roon database in memory allowing for a completely diskless RoonServer.  Obviously, this would mean you would need a NAS to store your music files but at this time, this is my preference anyway provided I have access to a good network switch.

[romaz]

On 10/20/2018 at 10:35 AM, zettelsm said:

 

Thanks for this.

 

Did you also try comparing SE direct to DAC, either this trial or in the past?

 

The reason I ask -- I recently tried a tX-USBultra powered variously by an Uptone JS-2,  Uptone LPS-1, and  Sonore Signature power supplies between my Innuos ZENith and Chord Blu MKII feeding a Chord DAVE DAC and didn't hear any particular benefit with the tX-USBultra, regardless of power supply.

 

I'm confident I'm familiar with the sound of my system, and the system itself is fairly revealing, so my experience would seem to fly in the face of common experience, at least here on CA.

 

Thanks for your comments,

 

Steve Z

 

When I was first sent an Innuos Zenith SE for evaluation, as I posted on another forum, I was impressed by it, especially in comparison to a dCS Network Bridge that I also had on hand for evaluation, but it was only after I followed the SE with a tX-USBultra that I felt my SQ had elevated to a level where the purchase of the SE was justified.  It was in combination with the tX-USBultra where I felt the SE was convincingly superior to the dCS Network Bridge and what I previously owned.  And just like you, I own both the Chord Blu 2 and Chord DAVE DAC.

 

Here is what is really interesting to me.  As I have posted, I was quite surprised when this cheap AudioLinux-based NUC that I stumbled upon outperformed my much more expensive SE but only when I powered my NUC with my DR SR7.  When powered by an SR rail from my SR7, I felt the NUC still had a slight edge over the SE but with the DR rail, the superiority of the NUC was incontrovertible.  During blinded tests, friends and family unanimously chose the NUC as sounding better than the SE.  

 

At the present time, I own 5 SR7 rails but only one of these rails is a DR (double regulated) rail.  When I had my SE, I was using my DR rail on the tX-USBultra and it's impact was clearly heard.  As I shifted my lone DR rail to my NUC, I was forced to use an SR (single regulated) rail from my SR7 on my tX-USBultra and I was quite surprised/disappointed to find that my tX-USBultra was now resulting in a clear step backward with respect to dynamics and tonal richness and smoothness.  It's not like I was powering the tX-USBultra with a cheap switching PSU but that's how the DR rail made the SR rail sound like and this highlights the importance of PSUs.  In my experience, good power still trumps good clocking.  With my DR rail powering the NUC, my system sounds better without my tX-USBultra and so at this time, I have my NUC directly connected to my Chord M-Scaler. 

 

As luck would have it, Paul Hynes made me aware that one of his SR7 buyers had grown tired waiting for their SR7 and it happened to be an SR7 with 2 DR rails and so he asked me if I was interested in taking it on.  Of course, I said yes and while I don't expect to receive this SR7 until some time in early 2019, after these recent revelations, I feel like I have struck gold. 

 

Just an update on these NUCs that Larry and I have been working on, we are planning on testing different NUC platforms including different CPUs, RAM with different timing, various storage media for the Roon database, etc., to see if we can agree on an ideal platform for both RoonServer and RoonBridge.  I will also be sending one of my NUC boards to SOtM for clock replacement to see where that leads.  While SQ is based on more than just latency, this is obviously an important metric and so Larry ran some latency tests on the Celeron NUC that we both own and got average latency readings in the 4-5us range.  Not as good as the 2.5us of latency of the Pink Faun 2.16 but very close and considering that this was achieved with hardware that cost less than $200 is astonishing.  

[romaz]

12 hours ago, TheAttorney said:

 

It would also be interesting to see how all this compares to The Linear Solution's DS-1, which, as I understand it, is a productized version of your NUC idea, plus his low latency operating system, plus ocxo clock on ethernet or USB, plus sprinkled with his own magic dust. It costs much more than a DIY NUC, but much less than a Pink Faun 2.16.

 

Adrian at TLS approached me last year about his novel Dream OS (his customized version of AudioLinux) that he said was a key feature of his "The One" server.  The concept of a RAM-based OS was immediately attractive but at the time, I had just finished building my single box custom server that I posted about here on this thread and so I wasn't really open to exploring his big box server. 

 

At some point, I began to yearn for a better server than the one I built that was completely devoid of a noisy SSD and when the NUCs with eMMC drives became available, my curiosity was piqued as eMMC, at least on paper, seemed to embody both the low latency of SSD and the electrical "quietness" of an SD card.  It was at that point that I asked Adrian if I could try out his OS on this particular NUC and he agreed.  This is how his DS-1 came to fruition.  

 

Hoping to differentiate his product offering from a DIY NUC, as you've stated, he has added his own optimizations to his NUC board including an OCXO to either the Ethernet port or to the USB port.  He looked into replacing the system clock but apparently has run into stability issues and so this option is not yet on the table.  As an endpoint, if only one clock can be replaced, I suspect the biggest gain will be to replace the USB clock although as a RoonServer, it would make sense to replace the Ethernet clock.  Ultimately, it is the small size of the NUC chassis that limits him to only a single clock replacement.  Regarding the NUC chassis, the chassis he is looking to use for this NUC is a real stunner and the nicest looking and most solidly built NUC chassis I have ever seen (better looking than the Roon Nucleus chassis which I think is a very classy looking chassis).  This chassis is very expensive and is part of the reason why his DS-1 costs more but this will be a NUC most people will want to display on their rack.  Based on how good TLS's switch and CAT7 cable sound, I have every reason to believe Adrian's winning trend will continue with the DS-1.  Ultimately, I believe it will be the quality of the PSU that truly sets the DS-1 apart from his competition and the beauty of this type of device is that an individual is free to choose.  For those looking for a turnkey solution that would have the potential to trample a $17k Aurender W20 for <1/10th the cost, give the DS-1 serious consideration.  Furthermore, Adrian is a super nice guy.

[romaz]

10 hours ago, Dev said:

It would be interesting to know how all these PSU rank.

 

This would be an interesting comparison to make and I think we would all be interested in such a shootout.  With regards to a NUC, aside from power supplies from Paul Hynes, TLS and Mojo Audio, you can also get a customized PSU from Sean Jacobs, Kenneth Lau, and Paul Pang.  While not customizable,  there is the excellent JS-2, the latest HDPlex with LT30451 regs, and well regarded offerings from Teradak and SBooster.

 

Competition is good for the consumer and I think it drives each manufacturer to continue to improve their own offerings.  For those who are in the SR7 queue and are willing to spend the money for the very best, based on demand, Paul Hynes is now offering the option of a Teflon circuit board to reduce dielectric absorption in the regulator circuitry and Vishay Z Foil ultra precision bulk foil resistors which reduce resistor noise and thermal drift to very low levels.  Paul has not yet told me what this upgrade will cost but I suspect it won't come cheap although based on how he described their impact, it will be worth every penny.

 

Lastly, I did not mean to suggest that for a component to be worthwhile, it needs a DR rail from an SR7.  My main point was to suggest that if you decide to employ a "spaghetti solution" of components, ideally, each component should be powered to an equivalent standard or else you will likely run into a bottleneck.  Given how well the Zenith SE is powered, if a component that follows it isn't equally well powered, you may get suboptimal results and so in some situations, a spaghetti solution may not be the best way to go.  As always, assume nothing and trust your ears.

[romaz]

1 hour ago, the_doc735 said:

A lot of talk scattered about NUC's in this thread.....

 

A throrn in the side of the NUC perhaps?

 

"Audiophiles want the best sounding playback system they can afford. Based on my functionality tests and listening sessions, the microRendu could be the solution. I've never had better sounding audio in my room with any other device or server or streamer. Period. Those who want the best must give the microRendu a spin". 

"commercial motherboards contain extremely noisy DC to DC converters and switch mode regulators. Thus, even though an expensive linear power supply may be used on the outside, the power signal is going through a gauntlet of garbage once it hits the motherboard on its way to the USB output that feeds power to the USB DAC". 

Chris Connaker.

see this

 

....seriously considering a rendu 1.4 which is essentially an early version of the ultrarendu, based on this review. Best bang for the buck and a case of diminishing returns for the more you spend. i.e. signature rendu, a lot of dosh for a small return!

I think the 'ultra' with a top end LPSU would be as good as it gets? (for the average punter! - not able to spend say £60,000 on a system)? General purpose mobo's could be 'last year' for me personally now!

 

Any comparisons of NUC Vs. Rendu please?

 

Cheers!

 

PS: NUC's contain commercial mobo's B.T.W.

 

 

Yes, I still own a microRendu.  As a small low impedance device designed from the ground up for high-end audio reproduction (unlike a NUC), you would think these small devices should rule the world.  No disrespect to the microRendu which was a landmark product upon its release but the NUC I am working with, with all of its noisy switching regs and clocks soundly outperforms the microRendu at 1/3 it's price.

[romaz]

5 minutes ago, the_doc735 said:

what price is that (1/3) please?

Cheers!

 

I paid $118 USD for this NUC:

 

https://www.bhphotovideo.com/c/product/1401554-REG/intel_boxnuc7cjyh1_intel_nuc_kit_nuc7cjyh.html

 

I paid $80 USD for 8GB of RAM:

 

https://www.bhphotovideo.com/bnh/controller/home?O=&amp;A=accessoryIntermediate&amp;Q=&amp;sku=1244579&amp;is=REG

 

A microRendu without a PSU sells for $640.

[romaz]

4 minutes ago, the_doc735 said:

Looks like a really good deal mate!

I have the opportunity of a rendu 1.4 (aka: ultra rendu) for $300 AUD?

With all respect, Do you have any justification for your statement that the NUC outperforms the rendu 1.3/1.4 ? Or is it based purely on listening? e.g. things like graphic charts superimposed ?

Your proof could influence my purchase decision! So it's quite important to me, at this moment in time!

Cheers!

 

I'm not sure what you mean by graphics charts superimposed?  If you mean measurements, no, I have no measuring equipment other than my ears to tell me how good something sounds.  In fact, you won't find any meaningful measurements for the microRendu either.  What I will tell you is that to my ears, the difference between the two is not subtle but don't take my word for it, do your own comparison.  These are not wildly expensive pieces and you should be able to easily re-sell or re-purpose the loser.

[romaz]

On 10/26/2018 at 7:39 AM, str-1 said:

Can I also take this opportunity to ask what spec your tX-USBultra is.  I know from past posts that it will have a clock input for use with the Mutec REF 10 but does it also have upgraded internal dc wiring (copper or silver) and EVOX caps?  I will soon be upgrading my tX-U for clock input (I think I’ll go for 75 ohms) and probably also the EVOX caps but I am unsure whether to upgrade internal wiring to the higher purity copper or to silver.

 

Hi Steve,

 

My tX-USBultra has the OCC silver DC wiring and 75-ohm clock input connector.  I will eventually send it to SOtM for the EVOX caps upgrade.  As it has 3 free clocks, I plan to use those 3 clocks for my NUC (once I decide which one is ideal).  I hope to eventually power it with a 12V DR SR7 rail but that SR7 won't arrive for some time.

 

[romaz]

A further update...

 

Larry was kind enough to send me updated USB sticks (one with RoonServer and one with RoonBridge) for testing.  They are a noticeable step up in SQ compared to the original USB stick he sent me.  Someone asked how this compares to TLS's Dream OS.  The version of TLS's Dream OS I have is older and is not headless (it has a GUI) while Larry is using the latest headless version of AudioLinux which further incorporates his own tweaks and so Larry's version is quite a bit better.  TLS's Dream OS, however, has been updated/improved by Adrian in the recent months (I don't have Adrian's latest version) and so the latency figures he posted on his site will undoubtedly be improved upon once his DS-1 starts shipping.  

 

I have tried running my Celeron NUC with 4GB vs 8GB.  I am unable to detect any meaningful difference in SQ between either configuration.  Larry did some testing and found the latency figures were the same with 1 RAM stick vs 2.  There's certainly no reason to spend the money on 8GB of RAM.  

 

I am currently using Crucial's Ballistix DDR4 which is slightly lower latency than their standard offering.  This only cost $7 more than their standard RAM and so I figured, why not.  I have not done any A/B comparisons with Crucial's cheaper RAM to know if this sounds better although I just purchased Kingston's HyperX DDR which is even lower latency than the Ballistix DDR4 to compare against.  Unfortunately, either this memory is defective or it is incompatible.  I can't get it to run and so back it goes.  I can vouch that Crucial's Ballistix DDR 2400 works fine and sounds great.

 

I then tried Larry's latest USB stick with RoonServer on my Celeron NUC.  This enables the Celeron NUC to function as a single box RoonServer + renderer.  Just like with my other NUC, this did not sound great.  If you don't compare, you can fool yourself into thinking this sounds good but as soon as I move RoonServer back to my Mac Pro and allow the Celeron NUC to function purely as a RoonBridge, it becomes easy to hear that the Celeron NUC as a single box server/renderer sounds thin and strained.  Roon most definitely benefits from distribution of tasks across multiple machines.

 

Unfortunately, I have not been successful in running headless AudioLinux on my Mac Pro and so I turned to my HP Z820 Workstation.  This PC incorporates an 8-core 3.4GHz Xeon with 25MB of SmartCache and 150w TDP as well as 32GB of RAM and fortunately, I was able to successfully run headless AudioLinux + RoonServer completely in RAM with this monster PC.  As I posted previously, when I used my older Celeron NUC with TLS's Dream OS as RoonServer and my newer "Larry" NUC as RoonBridge, transients sounded fast and snappy but the sound signature was thin, even with my SR7 powering both units.  With my Mac Pro as RoonServer, sound was fuller and richer and was easily the better sounding RoonServer machine.  This has led me to buy into Pink Faun's premise that for your RoonServer machine, "more is more."  

 

As good as my Mac Pro sounded as my RoonServer, the HPZ820 workstation running AudioLinux + RoonServer in RAM simply sounded better.  A LOT BETTER and it was one of those OMG moments!  Deeper, richer tone with better dynamics, better bass, better transients, better separation and better articulation.  Bingo!

 

I will next try an i7 NUC to see how it competes against my much more powerful HP Workstation to see if there is a drop off in SQ.  At this point, I'm not sure where the sweet spot will be for a RoonServer but at the very least, I now have a new SQ benchmark that is considerably better than anything I have ever heard in my system.

 

At this time, this is what I would suggest for those who are interested in following this path:

 

High power server > bridged LAN > reclocked switch > low power NAA 

 

Instead of a switch, Larry is using WiFi and he is pleased with it and so that may be a good option also.

 

Some have PM'd me regarding the use of players other than Roon.  At this point, I have only tested Roon.  Roon is ideal since it allows you to distribute tasks among multiple machines and I believe that to be key here.  Ideally, you want both a high power and a low power computer with the 2 isolated by a really good switch and with a bridged LAN connection isolating these devices from outside traffic.  At this point, it remains my belief (and I'm happy to be proven wrong) that x86 CPUs (either Intel or AMD) are where it's at.  I simply haven't heard an ARM-based machine sound this good.  As previously stated good power is paramount.  While I'm sure high-level clocking will add to the goodness, right now, the only high-level clocking I have is in my switch and yet, this sounds simply superb.  

[romaz]

22 minutes ago, greenleo said:

Hi Roy,

 

Are you using the HMS?  Once the clocks of the NUC are fed by the SCLKs from the txUSBUltra which is fed by the Ref-10 (or an even better clock), could a direct optical output from the NUC be better because RF is no longer a concern?

 

Unfortunately, the NUC's optical connections are not operational when running AudioLinux on this NUC.

 

I have both Hugo M Scaler and Blu Mk2 and Hugo M Scaler is noticeably superior to Blu Mk 2.  HMS now has a galvanically isolated USB input while Blu Mk2 does not.  With HMS, USB sounds as good as optical without the bandwidth limitations of optical and so I am happy to use HMS's USB input.

[romaz]

7 hours ago, vortecjr said:

You might want to get away from RoonBridge. Unfortunately, it requires Windows .NET in order to work on Linux. This is a far cry from an official RoonReady implementation where you run the actual C code right on the network endpoint without additional unnecessary stuff on top of it. Its just not an optimized way of doing things. 

 

As a manufacturer, I can appreciate why you would want to be RoonReady certified.  As a consumer, my top concerns would be SQ, stability, and compatibility.  Perhaps, that is what RoonReady certification is supposed to accomplish but with my NUC NAA, as I have run it both ways, with Roon Core (via RoonServer) or with RoonBridge, I have not run into any SQ penalties, stability issues, or compatibility issues.  With regards to stability, this completely diskless implementation with RoonBridge has been one of the most stable things I have seen.  I have not had a lockup yet and I have had full access to Roon's rich feature set.  With regards to compatibility, with the 4 DACs I have on hand, they all work without a hitch.  As for SQ, they are very close with RoonBridge sounding a little better.  

 

To me, this is one of the advantages of an x86-based NUC.  You can run anything on it, including full Roon.  With ARM-based endpoints, this isn't possible.

[romaz]

7 hours ago, seeteeyou said:

 

If Dawson Canyon (i7-8650U @ 800MHz with only 1 core enabled, therefore 8MB SmartCache should be unshared) were coming out on top, are you expecting that 24V DR SR7 rail could very well be the "Holy Grail" when it's connected to the internal 4-pin Molex connector?

 

https://ark.intel.com/products/130393/Intel-NUC-Kit-NUC7i7DNHE

 

Roon is now a multithreaded app and so it can potentially take advantage of all the cores your CPU has.  With RoonServer, I know for sure it is utilizing multiple cores.  With RoonBridge, this is not so clear. 

 

With RoonServer, it would seem that multiple cores, high clock rates, and large cache size all factor into lower latency.  The problem with high power is high noise.  Furthermore, you have cost, space, heat, and power consumption issues to contend with.

 

With RoonBridge (or at least with a Roon renderer), because so little else is going on except playback, the loftier needs of RoonServer don't apply which is why weak ARM-based CPUs can work but just because a weak ARM-based CPU such as a Raspberry Pi can function as a RoonReady endpoint, does that mean they sound best.  Thus far, this has not been my experience and so it will be interesting to compare something like a Pink Faun Scion, an ARM-based NAA which will also utilize AudioLinux, to a NUC to see which sounds better.  Pink Faun has suggested that the Scion will compete with their mid-level Streamer 3.4 which is to say their Scion is not expected to be a world beater.  At this point, I am betting on the NUC.

 

Regarding a 24V PSU, thus far, with NUCs, it has been my experience that higher voltage sounds better (more dynamic).  I have spec'd my incoming SR7 to have a DR 19V/5A rail and there were heat considerations to accommodate this requiring the use of a larger chassis.  I'm not sure what it would take to spec a DR 24V/5A rail and whether that would be necessary.  As the voltage goes up, current requirement should be less and I could probably get by with a 24V/3A rail but my experience has been that an over-provisioned rail sounds better.  Even if a tX-USBultra never fully draws a full amp at 12V, a 12V power supply with a 5A rating sounds better than a power supply with a 1A rating.  Having discussed this with Paul Hynes, he agrees and so with all of my SR7s, they are over-provisioned.

 

As for the 2X2 Molex connector on the NUC7i7DNHE, should I ultimately go with that board for either my RoonServer, RoonBridge, or both, I fully expect to use that connector.  Unfortunately, my Celeron NUC does not have that option.  

 

8 hours ago, seeteeyou said:

Besides, just wondering why you might decide to modify the clock for those on-board USB 3.0 ports instead of using tX-USBexp with M.2 to PCIe adapter. Does an adapter really degrade the signal THAT much?

 

Since AudioLinux should be able to support NVIDIA GPU, stuff like tX-USBexp should be no biggie.

 

It's possible that bypassing the on-board USB 3.0 ports and going with a tX-USBexp will sound better but this adds considerable complexity and it will be one more thing I will have to power to a high standard.  The biggest issue is finding a well made (minimally resonant) fanless chassis that can accommodate it all.  To be honest, this simple NUC without any special clocking is sounding so good as is that I could call it quits right now and be happy.  As Larry suggested, with this NUC, I feel like I am in the end game.

[romaz]

8 hours ago, spotforscott said:

 

Thanks Roy @romaz for your continued efforts to optimize digital and share your findings. Q: when you say "x86 CPU", how does the SonicTransporter i7 Intel i7 (Kaby Lake) quad-core processor line up vs x86CPU? thx  

 

Your SonicTransporter i7 should function capably as a RoonServer.  x86 applies to any Celeron, Pentium, Xeon, or i3/5/7 CPU (or the AMD equivalent thereof).  For RoonServer which performs the brunt of the heavy lifting, the more powerful CPUs seem to fare better but at what point are the benefits of lower latency outweighed by the negatives of higher noise?  While higher noise can be mitigated, as we have seen from servers like the Pink Faun 2.16 or Sound Galleries Evo, heroic efforts become necessary.  Also, what are the thresholds where SQ no longer improves?  Does 16-core sound better than 8-core or 4-core?  What clock rate is ideal?  How much SmartCache?

 

@vortecjr suggested that Linux already plays from RAM and uses RAM to speed disk operations.  This is true for all OS's, whether it be Windows, DOS, MacOS, or Linux.  But what we are talking about here is different.  It would make sense that because RAM is orders of magnitude faster than any disk, that to be able to avoid any and all disk access by running completely in memory is a big deal and my experience thus far strongly supports the validity of this approach.  Furthermore, to be able to avoid the noise imparted by a drive, especially an SSD makes this approach a slam dunk.  And so at the very least, figure out a way to run diskless, particularly with your endpoint.

[romaz]

7 hours ago, Cooler said:

 

 

Hello @romaz, can you please clarify. In one of your previous posts you claimed, that it doesn't matter what server we use (roonserver), if we use as the last device a reclocked switch in our chain, it will give top results. 

 

Do you still stick to this idea or in your last findings, you think, that powerful server (roonserver) with reclocked switch sounds better, than less powerful machine (roonserver) with reclocked switch. And of course in both situations we have roonserver machine -> reclocked switch -> roon renderer (sotm/sonore/dcs/custom pc/etc).

 

This approach seems complicated but it's simpler than it sounds and I believe the efforts are worthwhile.

 

Back when I first got this NUC and as I was comparing my highly optimized Zenith SE against my unoptimized Mac Pro as RoonServers, I assumed the Zenith SE would make a better RoonServer for my NUC but was surprised when that wasn't the case.  I surmised this had a lot to do with the SOtM sNH-10G network switch I was evaluating at the time because with this switch placed between my RoonServer machine and the NUC endpoint, the SE was not better.  For all practical purposes, I felt that they sounded equally good.

 

My bubble was burst a bit when I did notice a difference between my Mac Pro and my older NUC when both were used as RoonServers and I did post about this disappointment on October 16:

 

 

At that time, I estimated that the NUC endpoint was accounting for at least 80 percent of my SQ while the RoonServer was accounting for at most 20 percent.  In my own words from that post, I suggested that "this bodes well because a good renderer costs a lot less than a good server and so I am hoping this observation stands the test of time."  Unfortunately, this observation has not stood the test of time because what I'm hearing now with my HP workstation running AudioLinux in memory is probably accounting for something like 35-40% of SQ but clearly, the NUC endpoint is still the more impactful device.

 

To confirm this, I removed my NUC endpoint from my pathway and decided to see how my HP workstation fared by itself.  I had my HP workstation boot into Windows 10 which is its normal configuration.  Running Roon in this normal configuration, I compared it to headless AudioLinux running in memory on this same machine and the improvement was dramatically better with AudioLinux.  However, compared to having the low powered NUC endpoint in the chain, the HP workstation by itself sound coarse and edgy.  With the NUC powered by my DR SR7, sound floor was very evidently lower resulting in the ability to discern fine details better.  The presentation was smoother and calmer and yet dynamics were very noticeably better.  One of the things I really value is the proper rendering of the transients created by an acoustical guitar.  In a live setting and in a good acoustical space, the leading edge is sharp and clear and has a snap to it and yet the reverberations are finely layered and nuanced with a very characteristic lingering decay.  The ability to portray this is a chief reason I gave up my Pass Labs amp for a Soulution amp and especially with the DR rail from the SR7, this is what I'm getting with the NUC that I am not hearing to the same extent with just the HP/AudioLinux server by itself.  

 

So what I am saying now is that the RoonServer does matter (and it matters a fair amount) and the RoonServer has to be powerful but this cheap NUC still accounts for the greater difference.  

[romaz]

6 hours ago, ajm said:

Very interesting to hear you find HMS superior to BluMk2. Is this using the stock PSU for HMS?

 

Andrew

 

Even with the stock PSU, HMS is better sounding than Blu Mk2.  Does HMS improve with a better PSU?  Absolutely, yes, which makes a further case for the HMS. 

[romaz]

1 hour ago, Johnseye said:

Roy and Larry's findings are in direct competition with a Roon ready device.  Just throwing that out there.

 

Yes, but we have no skin in this game except to find what sounds best.

[romaz]

12 minutes ago, agillis said:

 

You could PXE boot Linux over the network and run a computer completely from RAM with no hard drive, SSD, or boot drive of any kind. This is not that hard to do and there are instruction on the internet to set up something like this.

 

But from my experience you would still be subject to all the other electrical noise in a computer. The best option is always to separate the server from the network player The configuration would be to use a network player with a small Linear supply powering each component on the board, not SSD drive and a small low power low noise ARM CPU.

 

This way you would eliminate all the noise from SSDs etc, all the noise from switching power supplies, and all the noise from large fast CPUs. This design is already available commercially. It's an ultraRendu.

 

Your jumping into this without a full understanding of the context of what has already been discussed.

 

I wasn't going to name names but this cheap NUC we are talking about is completely diskless while the ultraRendu is not.  Even a microSD card creates some noise to the extent that people are reporting differences when they swap out the standard microSD card with an SLC card.  Furthermore, a microSD card is not a low latency drive.  Lastly, as I've stated, I'm not so sure a low noise ARM CPU sounds better than an x86-based CPU when it comes to Roon.  Having heard both the ultraRendu and even the Signature Rendu SE on several occasions, while these are very good sounding devices, to my ears, I would say they are roughly on par with a similarly well powered SOtM sMS-200ultra.  This cheap NUC with its noisy switching regulators is performing at a higher level.  

[romaz]

11 minutes ago, agillis said:

 

You should never connect a sonicTransporter i7 to your DAC. You are correct the i7 processor is very noisy. This is why you need a network player to isolate your DAC from the noise.

 

 

 

I believe this is what I have been saying all along.

[romaz]

Just now, agillis said:

So how do you boot the NUC if it's diskless?

 

You boot off a USB stick and once booted, you remove the USB stick.

[romaz]

2 minutes ago, agillis said:

 

Have you tried PXE boot? It would save you from having to plug and unplug the USB key all the time.

 

it would just boot up and run. No drives. Ever.

 

Yes, this has been discussed earlier in the thread.  However, booting from a USB stick and then unplugging it has not been a big deal.  The latest iteration of AudioLinux has been just as stable as your SonicOrbiter.  The only time I have to reboot is during comparison testing.

[romaz]

6 hours ago, Superdad said:

 

 

I am echoing Cooler's question with the above quotes:

 

Certainly your thoughts and impressions are allowed to evolve as you experiment.   But I am wondering if Roon is the real factor in what you are now hearing with server differences.  Wonder if you still feel the same if HQ Player NAA protocol was used.  

Would like to separate hardware versus software factors.  E.g.: With a good switch in the chain, does power supply of the server still matter for you?

 

Cheers,

--Alex C.

 

Alex, I think Roon is one of several factors but it remains to be seen what contribution the CPU, chipset, bus architecture, OS and player are each making.

 

At this time, I only have the TLS switch on hand and so how well it is isolating the impact of server's power supply versus the SOtM switch or your soon to be released switch is unclear.  With the TLS switch, the quality of the PSU to the server is audible.  Having said that, I find a good switch contributes A LOT and based on many private conversations, I know many are holding off on purchasing a switch until your switch becomes available.  

 

Someone else will need to answer how all of this impacts HQP but I would guess that it all applies.

 

While there are tools to measure CPU, I/O, and OS latency, the more useful tool would be to be able to specifically measure Roon latency.  Roon has made their recommendations with regards to minimum hardware requirements which includes a fast CPU with large cache and SSD but their emphasis for these recommendations isn't SQ but rather usability which includes a snappy interface and a brisk library browsing experience.  In fact, most of the talk on the Roon forums centers more on features than SQ which is disappointing.

[romaz]

7 minutes ago, austinpop said:

 

Hi Roy,

 

This is a significant finding! However, while running RoonServer in RAM is an interesting exercise, what do you see as the long-term solution, since Roon Server needs to do I/O's to storage as part of its normal operation, due to:

• library changes, requiring updates to the Roon DB
• version upgrades
• backups
• etc.

In your experience, can this be handled by the ramsave command? Or do you have to be disciplined - whenever you want to make changes to Roon, reboot answering N to ramroot boot prompt, make the necessary changes, and then reboot again in ramroot mode?

 

This is all very exciting!

 

Larry brought up these issues and his solution is to maintain the Roon database on an Optane drive.  I have not tested this but it makes sense.  In theory, this drive probably won't be accessed too often and hopefully, will contribute more positives than negatives.  Right now, the Roon database is completely on the USB stick and so with the RoonServer machine, I am unable to unplug the USB stick.  Having said that, everything is working smoothly and so there would also be the option of using something like a 64GB USB stick as nonvolatile storage for the Roon database.  For those with a giant library, it will impact the browsing experience as it will be slow and so that would be the downside.

[romaz]

If anyone deserves to monetize what has been learned here, it is Larry.  His contributions ranging from JSSG360 to the tricky implementation of AudioLinux in some of these NUCs with quirky BIOSes are much appreciated.  True to his giving nature, Larry has refused to thus far accept any compensation from me for his time and even for shipping.  

[romaz]

13 minutes ago, seeteeyou said:

 

Could an eMMC drive (with USB adapter) provide decent performance as well as relatively low noise?

 

https://www.pine64.org/?product=usb-adapter-for-emmc-module

https://www.pine64.org/?product=64gb-emmc

http://www.foresee.cc/en/Business/index.asp?itemid=93

 

Yes, Larry is currently using the eMMC drive in his dirty NUC for Roon storage and he indicated to me that he is pleased with this solution, however, eMMCs are generally not an option with the higher powered (non-Celeron) NUCs.  eMMCs are by definition "embedded" and so I am not aware of a USB eMMC drive.

[romaz]

6 minutes ago, austinpop said:

 

If, as we suspect, the audio benefit comes from reducing latency, then it would seem beneficial to load the Roon DB into RAM as well, as part of the ramroot configuration.

 

I did a quick check on my W10 Roon Core, to see how big the Roon DB really is. My Roon library has ~1500 albums for a total of ~14000 tracks. I estimated DB size by looking at the size of the following directory: %localappdata%\Roon\Database, and it is 1.27GB. Indeed the whole %localappdata%\Roon directory is 1.75GB.

 

Assuming a machine with a generous amount of RAM (16GB?), is there any reason why it wouldn't make sense to just load this into RAM at boot? Obviously, it does take discipline to make non-volatile changes, like booting in non-ramroot mode before making any changes.

 

Larry and I discussed this and it is possible to do it, however, we both question whether the Roon database (and it's access) has any impact on SQ.  As far as we know, the database is there for administrative reasons.  The challenge of placing it in RAM and going completely diskless with the RoonServer is that you won't have knowledge of available Roon updates unless you reboot the machine and given the stability of this setup, I may never have a reason to reboot the machine.  Furthermore, a 64GB Optane drive only costs about $50 and you'd never have to worry about data loss in the event of a power outage.  

 

With that said, if it turns out the Optane drive results in SQ detriment, perhaps it would be worth doing.