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

[soares]

4 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.

Any time soon the good switch? ?

[Johnseye]

4 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.

 

4 hours ago, auricgoldfinger said:

 

+1

 

3 hours ago, rickca said:

I would also like to know the best way to use NUC/AudioLinux without ROON in the picture. 

 

A lot of us here use HQPlayer from Roon.  @lmitche have you tried using HQPlayer as a NAA on the NUC?

 

My NUC should be arriving any day.  Once it does I will be doing this.  Audiolinux from RAM running Roon on my current PC to the NUC running HQPlayer powered by my SR7 DR rail.

[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.

[d_elm]

5 hours ago, rickca said:

Intel and AMD processors (like in your SonicTransporter i7) use the x86 architecture.  Roy is contrasting such CPUs to ones based on ARM architecture (like Raspberry Pi).

x86 is a complex instruction set and ARM is RISC.  Perhaps the extra memory access of a RISC processor to get anything done is the difference.

[the_doc735]

15 minutes ago, romaz said:

 

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.

a diskless server? available off the peg? 

cheers!

[agillis]

20 minutes ago, the_doc735 said:

@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.

 

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.

[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.

[agillis]

56 minutes ago, romaz said:

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?

 

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.

 

If you want features like DSD512 upsampling an i7 is the only way to get it. You then need a way to seperate the noise from your DAC.

 

 

[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.

[agillis]

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

[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.

[agillis]

1 minute ago, romaz said:

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

 

Yes you have been saying that. This thread is very long I was mentioning it again for people who are still talking about attach a DAC to an i7 CPU machine.

[agillis]

1 minute ago, romaz said:

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

 

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.

[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.

[agillis]

Just now, romaz said:

AudioLinux has been just as stable as your SonicOrbiter.

 

Linux is in general very stable. I have a system here that has not been rebooted in 5 years. That's one of the reasons it's so great for audio.

[austinpop]

11 hours ago, romaz said:

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!

 

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!

[lmitche]

2 minutes ago, agillis said:

 

Linux is in general very stable. I have a system here that has not been rebooted in 5 years. That's one of the reasons it's so great for audio.

This is DIY thread. Aren't you a vendor? Your comments are way out of context. And yes, it is a long context littered with false starts, dead ends and moments of complete joy on many occasions over many years.

 

Everything you are saying true and we have collectively been there and done that. We are on new path with the NUCs, turning over many new rocks.

 

Please let us have this space to do so.

 

Thanks,

 

Larry

[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.

[agillis]

1 minute ago, lmitche said:

This is DIY thread. Aren't you a vendor?

 

This is a DIY thread. and yes I am a vendor. All of my products started as DIY ideas. We improve them productize them and bring them to the masses in the form of easy to use products.

 

But it all starts with people working together to try new possibles.

 

Turning over new rocks is how all great products start.

[agillis]

12 minutes ago, austinpop said:

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:

 

What if you mounted a network drive and wrote the changes to that once and a while?

[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.