Jump to content
austinpop

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

Rate this topic

Recommended Posts

hi guys, my first post in C.A...and my question is : i want to purchase the Roon license. my system is on build and i want to connect the endpoint in a lan bridge (with a dual lan card), so : what Roon i need ? Server, bridge, core ? once i purchase the license, can i swap the system software or i die with one ?

i question that because my renderer in fist instance will be a Allo USBridge lps and battery powered, then migrate to a nuc celeron with emmc or a Sonore mrendu. Thanks ! 

 

Share this post


Link to post
Share on other sites
6 hours ago, elpampeano said:

hi guys, my first post in C.A...and my question is : i want to purchase the Roon license. my system is on build and i want to connect the endpoint in a lan bridge (with a dual lan card), so : what Roon i need ? Server, bridge, core ? once i purchase the license, can i swap the system software or i die with one ?

i question that because my renderer in fist instance will be a Allo USBridge lps and battery powered, then migrate to a nuc celeron with emmc or a Sonore mrendu. Thanks ! 

 

 

Don't worry - your Roon license is completely portable. It's associated with your Roon account. If you switch servers (or OS instances), you'll be asked (eventually) if you want to deactivate the previous device so you can enable the new one.

 

You only need a license for the Core (server). You can have as many renderer/endpoints, running Roon Ready/Roon Bridge, as you want. :)

Share this post


Link to post
Share on other sites

For those on the fence reading this, I tried Euphony to see for myself if a Linux OS works. Not that i didn't  think it wouldnt..

https://euphony-audio.com/installation/

30 free days only.

I saw it on another thread but its not DOS style Linux commands. For a novice like me its a bit uncomfortable but not so bad getting it to work..

Download a trialzip. Run exe file onto a blank 8 G memory stick. Reboot and go into your bios F2 and pick the memory stick. Thats the pc part.  Follow thier instructions on another pc or phone just on your network wifi. The web page gets you to start a trial.. you have too figure out where your music is and mount it in settings. Not easy for me but got it working eventually. 

Will i invest in a NUC PC? My old gaming PC was better than Android phone 5% 

With Linux 10-15% IMHO.

I am not endorsing this product or any other but it allowed me to try with no investment or linux knowledge. (I have liitle of either..)

There seems to be a lot of mileage with these kind experiments, on our behalf left to go. 

So i can't  wait and see the end recommendations in its basic form and whats possible.

 

I can't afford much more than a cheap NUC PC and thats in the sales Jan 2019 and many like me have no real clue of Linux until this thread. Or the Intel NUC.

Reverting back is as easy as just removing the memory stick from my computer..

 

I hope this helps some try this out, or another easier way is mentioned for free.

The point being it does work for me and flacs sound much better. Whatever your personal circumstance have a go and see. 

 

Roon, fancy power or cable mods can come later. Or a computer degree...

*Web page on my phone, capture

*My simple test setup to try Linux on my old PC. Qutest, 3 ifi filters, 5v battery and headamp.

 

Good luck and thanks again for improving my music..

 

Dave

 

1744620079_Screenshot_20181028-200521_SamsungInternet.thumb.jpg.9162980da6eb75513fc138db0944a378.jpg

 

20181028_192706.thumb.jpg.325cb10d603b74ba00fafd1d1f1302d3.jpg

Edited by Middy
Spelling.. Bod english

Share this post


Link to post
Share on other sites
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.

 

Share this post


Link to post
Share on other sites
44 minutes ago, romaz said:

 

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.

 

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?

Share this post


Link to post
Share on other sites

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. 

Share this post


Link to post
Share on other sites
2 hours ago, romaz said:

As it has 3 free clocks, I plan to use those 3 clocks for my NUC (once I decide which one is ideal).

 

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

 

On 8/10/2018 at 3:01 PM, romaz said:

During my testing with my SR7s, 19V sounds a little better than 12V but DR (double regulated) 12V sounds considerably better than 19V.  The ideal SR7 for this board would likely be a DR 19V which I do not have.

 

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.

Share this post


Link to post
Share on other sites
1 hour ago, romaz said:

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

1

 

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  

Share this post


Link to post
Share on other sites
3 hours ago, romaz said:

 

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.

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

 

Andrew

Share this post


Link to post
Share on other sites
On 8/8/2018 at 4:29 AM, romaz said:

To be honest, the above findings were expected rather than revelations.  What was a revelation was how well this switch now isolates the renderer from the server.  When I first described the impact of introducing a reclocked switch into the "direct" pathway, I was using only low-noise, high quality servers exclusively.  By this time, I had already established that the quality of the server matters and so I never bothered to go back to my noisy Mac Pro with 12-core Xeon.  In this instance, with the reclocked switch in the "direct" pathway, I decided to swap out my [Zenith] SE once again and replaced it with my noisy Mac Pro and what I found was truly revelatory.  This switch very effectively isolated the noise coming from the Mac Pro.  As I A/B'd between SE and Mac Pro, the difference between the 2 was now subtle at best.  In blind testing, I was unable to tell that there was a meaningful difference at all. 

 

 

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

 

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.

 

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

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

 

Certainly your thoughts and impressions are allowed to evolve as you experiment. 9_9  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.

Share this post


Link to post
Share on other sites
4 minutes ago, Superdad said:

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? 

 

+1

Share this post


Link to post
Share on other sites
5 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. 

 

.NET and Linux ? Is there a RoonReady available for the NUC ? Or are you suggesting to run the Roonserver instead of the RoonBridge ?

Share this post


Link to post
Share on other sites
6 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. 

Jesus R,

 

You seem to be suggesting we run software other than Roon. That's cool. I am sure Audiolinux can run anything you can think of. What would your recommendation be for best SQ?

 

Larry

Share this post


Link to post
Share on other sites
6 hours ago, vortecjr said:

You might want to get away from RoonBridge. Unfortunately, it requires Windows .NET in order to work on Linux.

I don't see .NET core runtime in the dependencies for Roon Bridge on Linux in the Roon documentation.  I guess you're saying it won't perform like a Roon Ready certified network player from a partner like Sonore.

Share this post


Link to post
Share on other sites
10 minutes ago, lmitche said:

Jesus R,

 

You seem to be suggesting we run software other than Roon. That's cool. I am sure Audiolinux can run anything you can think of. What would your recommendation be for best SQ?

 

Larry

 

Actually, Jesus @vortecjr is raising a very interesting point. I have always wondered what the difference was between "Roon Bridge" and "Roon Ready." It seems Jesus is saying that Roon Bridge is a containerized version of the code, meant to run in a .Net runtime, while Roon Ready can be directly compiled to match the HW of the device.

 

The question then is - do non-licensees of Roon Ready have access to the code? I know endpoint vendors like Sonore and SOtM run Roon Ready, but can hobbyists like us - really, like Larry! - get access to Roon Ready modules?

Share this post


Link to post
Share on other sites
On 10/27/2018 at 3:07 PM, seeteeyou said:

No love for 14.318MHz then, maybe Neutron Star 2 could support that but not sure.

 14.318MHz or kHz? This looks like real time clock. Not chipset/system clock ;)

 

What is your motherboard again?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
5 minutes ago, romaz said:

 

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.

 

I have ran RoonServer vs RoonBridge on the Celeron NUC (same one that you guys are using) as a streamer.  Both of them were ultra stable without any glitch. I have ran two DACs without issues. I also couldn't figure any audible differences between them. So in terms of SQ, stability and compatibility, I don't see any differences.

 

That post seem to suggest that RoonReady devices use a different s/w code base than the RoonBridge does and if that code (a compiled version maybe) can be made available on a NUC, we don't really know if it would benefit the SQ even further - maybe it will, maybe it won't. Interesting post from JesusR though.

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×