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

[hols]

14 hours ago, seeteeyou said:

Gosh, Cybershaft OP20 ($5,000) turned out to be a quantum leap when compared to OP17

 

http://www.hiendy.com/hififorum/forum.php?mod=viewthread&tid=122411

 

They're only talking about the bare minimum when OP20 was tested, stock clock cable plus an ordinary Acoustic Revive Power Sensual 18000 that's nothing to write home about.

My Audio Clock Journey

 

Hi CTU

I am not so slow this time. I got my Cybershaft OP20 Limited 2(same as Ultimate but with 3 outputs instead of 1 output ) a month ago and has been burning it continuously for a month now.  And it is about time to give a review of my audio clock journey as it has probably come to an end(really end game).

I started to use master clock way back 15 years ago when I use the Drawmer M-clock with my Prismsound ADA8.  My next clock is the Antelope Trinity + 10M(rubidium) about 10 years ago when I started my CAS journey using Linux OS and RME AES soundcard which like many professional equipments has a clock in in order for all equipments to use a synchronized clock. As has been discussed a lot in these pages that the majority opinion is saying that using internal clock is often better than using an external clock because of deterioration during the transfer of the clock signal. There is probably no dispute in professional gears because of the need to synchronisz multiple gears so using a master clock is often beneficial. However I think a lot of other factors need to be taken into consideration including 

(1) Accuracy of the clock --- a femtoclock is so much more accurate than a clock in the range of ppm

(2) Phase noise of the clock -- this is often not stated in many clocks but this is probably by far the most important determinant of whether an audio clock can give good sound or not.

(3) Power supply-- I remember that after using Paul Hynes SR9(old type) instead of the stock SMPS of the Trinity and 10M the SQ jumps significantly for my Antelope Trinity & 10M although I have also waited for more than 1 year before delivery 7 years ago.

(4) clock cable used

There is often a combination of these factors in coming to a final result and of course the final judgment is your own ears and see whether or not the resulting SQ improvement is justified or not.

For me the Antelope Trinity +10M has stayed in my system for 6 years and served my RME AES soundcard, EMM Labs transport and Dac6e, MSB DAC IV. It has persistently improved the SQ by giving both a more precise soundstage layout, better timbre and instrument focus. The 10M especially give a warm and more analog feel persistently.  They are actually very helpful in giving a much more analog sound when coming to high resolution files because in the early stages of high resolution files are typically very harsh. All over these years we have had comparison with other clocks including Esoteric P0 and the Antelope can still stand all the competition.Then came the Cybershaft claiming that the rubidium advantage of long term stability is not suited for audio and the OCXO has a better short term accuracy is more suite to audio. I was a bit slow and can only get a Premium OP13 initially but it is already good enough to kick out the Antelope 10M. It is at about this time when I added the SOtM txUSB ultra and the OP13 is attached to the SOtM. I gradually escalated to OP14 when I got a chance. The improvement of OP14 over OP13 is very significant as one of my friends commented it is like upgrading to a much higher level DAC. In May this year I changed to the Mutec Reference 10 and yes it is better than the Cybershaft OP14 by a wide margin both in stage layout and in instrument timbre. But most importantly it gives a warmer and more analog sound than the OP14. I think this is because it has a better phase noise at -116dB compared to -114dB in OP14. Secondly the power supply may be better in Mutec.

And when this new generation of OCXO type 2 clocks from Cybershaft comes to the market with such a high price range and that I have only changed to Mutec for 4 months it is really a dilemma whether I should go ahead or not. I consider myself lucky to have decided to buy the OP20 early which is quickly sold out. And on connecting the Cybershaft OP20 for 30 minutes I know that this one is definitely worth it. The sound is so natural and like going to a concert. The last bit of harshness is gone. One of my friend cannot stand my system being so detailed and sometimes a bit powerful on the ears when it comes to a double forte passage so he used to stay in the back seat instead of in the golden seat. But now he commented that it is very enjoyable now in the golden seat.  As was well said in the review in our local forum, the OP17 is like looking through a very well cleaned glass window and for OP20  there is no more glass there. And it is also true to say that the improvement from OP13 all the way to OP17 is incremental step by step but when when you get to OP20 you know that you are leaving this world and entering Elysium.  

At about this time the Habst cables arrived and I will report on the different clock cables later.

 

 

[elpampeano]

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 ! 

 

[austinpop]

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.

[Middy]

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

 

 

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

 

[greenleo]

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?

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

[vortecjr]

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. 

[seeteeyou]

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.

[spotforscott]

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  

[Cooler]

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

 

2 hours ago, romaz said:

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

 

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

[ajm]

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

[rickca]

3 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  

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

[Superdad]

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

[auricgoldfinger]

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

[rickca]

23 minutes ago, Superdad said:

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.  

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

[Dev]

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 ?

[lmitche]

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

[rickca]

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.

[austinpop]

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?

[rafa]

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?

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

[Dev]

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.

 

[Johnseye]

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