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

[seeteeyou]

For an Intel NUC without eMMC storage, maybe we could actually boot Windows off any SATA drives inside USB enclosures. Once we're done with the booting into RAM, that USB enclosure could be powered off and therefore it's completely diskless with zero noise.

 

Anyways, some of us should be interested in comparing diskless Supermicro X10SBA-L versus diskless Intel NUC with Celeron. Of course running Windows would be a challenge because each VHD image must be kept quite a bit less than 8GB as either Bay Trail or Apollo Lake couldn't support more than 8GB of RAM.

[dbq5anlxj]

4 minutes ago, seeteeyou said:

For an Intel NUC without eMMC storage, maybe we could actually boot Windows off any SATA drives inside USB enclosures. Once we're done with the booting into RAM, that USB enclosure could be powered off and therefore it's completely diskless with zero noise.

 

Anyways, some of us should be interested in comparing diskless Supermicro X10SBA-L versus diskless Intel NUC with Celeron. Of course running Windows would be a challenge because each VHD image must be kept quite a bit less than 8GB as either Bay Trail or Apollo Lake couldn't support more than 8GB of RAM.

Some Apollp lake board do support 16GB Ram ilike the Filter one and the asrock.

[seeteeyou]

Oh man, sometimes we shouldn't trust Intel too much then

 

https://ark.intel.com/products/95594/Intel-Celeron-Processor-J3455-2M-Cache-up-to-2_3-GHz

 

I guess that Auto Correct changed Fitlet to Filter automatically. Anyways Asrock seemed to be an interesting option for $160

 

https://www.asrock.com/nettop/Intel/Beebox%20Series%20(Apollo%20Lake)/index.asp
https://www.superbiiz.com/detail.php?name=MB-BEB3455

Quote

Inte Pentium® J4205 & Celeron® J3455 Quad Core CPU
Dual Channel DDR3L SO-DIMM (Max. 16GB)

 

(Could "Inte" be some kinda knockoff stuff? LOL)

 

Now we just need to figure out if booting the entire OS into RAM were playing the most important role or otherwise. Basically we could put any VHD images on any drives as a starter. Then the drive itself could be either powered off or unplugged after the OS itself is ready.

[Johnseye]

5 hours ago, lmitche said:

John, sorry not to be clear, it is the physical distance between the server and nuc that matters. 20 feet may not do it.

 

Right.  If I incorporate a NUC as endpoint, which I'm likely to try now, I would use a 6" or 1' ethernet cable.  Likely 360 shielded.

[ElviaCaprice]

9 hours ago, romaz said:

 

No doubt that this NUC board can be further improved, Mark, but it is impressive to hear how good this thing sounds "as is."  And running an OS from memory doesn't guarantee low latency if the OS is inefficient and has lots of unnecessary processes/threads running and if inefficient drivers are being utilized.  Sometimes, the bottleneck is in software and not in hardware which is why it was interesting to see the wide range of 10-150X less latency that was reported when this OS was run from RAM vs a PCIe NVMe SSD.  Also, RAM should have way more than just 10-150X less latency than an NVMe SSD and so obviously, a well-tuned OS matters.

 

I just can't get my head around it all, your findings.  Clocking/power on main server not mattering, 1 tweaked out audio switch making it all good.   Maybe Rob was right, all your doing by isolating the NUC at a distance and using the switch is preventing RF/EMI noise from seeping into your audio stream and corrupting the DAVE/HUGO2?   Maybe a little J/S 360 treatment and better isolation treatment at the server is all that was needed?   Maybe Chord DAC's don't need all this master clocking, clocking board, high buck power supplies in a server?  Just run an optical connection from a battery powered MAC as Rob does.  

 

Of course, in your case, running 2 rooms this setup makes sense.   But I can't buy the fact that this off the shelf NUC with just a tweaked out Linux OS loaded to memory and powered by an SR7 can be the answer.  That motherboard USB connector to your Chord component has to be awful?   Will be interesting to hear your impressions as you play around with this NUC as you say you will.

  

I may have to buy one of these NUC's to play around with, OS's, which by the way I find make no difference on my sCLK EX NUC, currently (but not from memory).   The switch is outside my single room needs for bit perfect.  That's what my tXUSBexp card is for as last endpoint before DAVE/future M-scaler.  

 

As usual, I will live thru your experimentations, which I'm grateful you share here.

[Superdad]

4 hours ago, lmitche said:

LOL! Thanks for your reply and yes indeed I am an upsampler in a world full of (what's the word?) non-samplers (no), un-samplers (not right), regenerators (already taken), or samplers (makes sense I guess but boring)..

 

You are a convoluter Larry.   

[lmitche]

20 minutes ago, Superdad said:

 

You are a convoluter Larry.   

Hah! nope no convolution happening here. I do admit to upsampling!

 

[look&listen]

5 hours ago, lmitche said:

I am an upsampler in a world full of (what's the word?) non-samplers (no), un-samplers (not right), regenerators (already taken), or samplers (makes sense I guess but boring).

Maybe "same-old-sampler"?

[PeterSt]

4 hours ago, seeteeyou said:

Could this be even better than eMMC or what? Simply boot the VHD image off USB disk and then unplug that afterwards

 

Diskless Windows 10 PC Setup Procedure

 

 RAM-OS.

 

 

[lmitche]

6 hours ago, lmitche said:

Flkin,

 

First off, thanks for sharing your experience with the conduit. Your positive experience helped me pull the trigger on this experiment.

 

With the 3/4 inch braid over the jssg 360 lush cable there is no impact on sound stage size here so I am surprised to learn you have an issue. The lush cable carries DC to my USB powered DAC and that power comes from a lt3045 chain.

 

Is your DAC powered via USB? If so, how? Could you could have an impedance or power  issue that is related with the increased dynamics? I have to admit that I anticipated an issue with the mumetal such as your sound stage compression and am pleased to have dodged that problem. Maybe the braid is a better solution?

 

My application of the conetic braid here is as simple as possible. I'm am just placing the cable in the braid avoiding an electrical connection at either end.

 

After listening to the braid on the lush cable the addition of the braid to the Gotham power cable adds another level of refinement, more detail and density in the treble and bass. For example I can hear whole cymbals in many more tracks now.

 

Two more Gotham cables will be treated with the braid today. One that carries power from an lps-1 to my USB card, and the second powering my router/switch. I expect a big impact from the first, and little from the second, but who knows?

 

Stay tuned!

 

 

 

 

Flkin,

 

While I am not done yet, I keep getting distracted by the music, I found the Lush cable sounds better without the Mumetal.  Instead I have applied it to dc power cables, one at a time, with listening sessions after each run is treated.  So far I have the Mumetal braid on both the ISO Regen feed from an lps1.2 and the USB card feed from an LPS1. Next I opened the PC and covered the big 8 conductor 12 volt CPU/EPU cable to the motherboard.  Each application adds a level of refinement, with the big CPU/EPU cable change the largest so far. This makes sense to me. Each of these cables are single or dual gotham jssg360s.

 

I am currently procrastinating application of the last run between the sigma 11 and the hdplex 400 watt smps powering the big 24 pin ATX connector side of the motherboard. The music sounds spectacular.

 

More stay tuned.

 

Larry

[austinpop]

1 hour ago, look&listen said:

Maybe "same-old-sampler"?

 

Or native-sampler?  

[austinpop]

13 hours ago, romaz said:

2.  Rajiv told me he recently performed a direct comparison of his Zenith SE against an sMS-200ultra and even with the sMS-200ultra powered by an SR7, he found the SE to be superior to the sMS-200ultra.  Some time ago, Rajiv, et al, directly compared the sMS-200ultra against the ultraRendu and found them to be comparable.  To paraphrase his post, I recall that he stated that if he owned one of these units already, there would be no compelling reason to switch to the other even though he had a personal preference for the sMS-200ultra.  This would suggest that Rajiv believes his Zenith SE sounds better than the ultraRendu.  Rajiv, please feel free to correct me if I have misrepresented your findings.

 

Yes, that is correct. As background, I'd like to remind people I was a staunch supporter of the endpoint/streamer approach, and regarded the direct attach approach as inherently flawed. But in light of what I experienced with the OCXO stitch > SE > tX (with Ref 10) chain, I accepted that there was more to this than met the eye, and to follow the evidence (at least my ears), rather than my belief.

 

Ever since Roy told me of his findings with the NUC/SR-7,  I've been wanting to corroborate it in my setup, but I have never had both the NUC and SR-7 at the same time. 

• As I posted a short time ago, my experience with generic NUC and SR-4 was not as good as the Zenith SE, but it could be because I did not have eMMC and SR-7
• I too was curious why this finding did not apply to the sMS-200ultra, so I tried the experiment Roy mentioned, with the sMS-200ultra powered by the SR-7. And just as before, this did not exceed the SE.

So the working conjectures to explain Roy's findings are (let's not even call them hypotheses):

• eMMC over SSD
• Intel CPUs over ARM
• in-memory "Dream" OS (Linux based)
• SR-7 DR rail
• something about the NUC mobo.

[Johnseye]

10 minutes ago, austinpop said:

 

 

So the working conjectures to explain Roy's findings are (let's not even call them hypotheses):

• eMMC over SSD
• Intel CPUs over ARM
• in-memory "Dream" OS (Linux based)
• SR-7 DR rail
• something about the NUC mobo.

 

Mysteries to be solved through much experimentation, music listening and libations.

[nbpf]

12 minutes ago, austinpop said:

...
So the working conjectures to explain Roy's findings are (let's not even call them hypotheses):

• eMMC over SSD
• Intel CPUs over ARM
• in-memory "Dream" OS (Linux based)
• SR-7 DR rail
• something about the NUC mobo.

It should be easy to support/confute conjecture 4 (SR-7 DR rail) by replacing the SR-7 with another PSU. Perhaps it would also be useful to check whether loading the OS in RAM makes a difference or not. In the latter case the kind of storage (eMMC vs SSD) might again become significant.   

[lmitche]

5 hours ago, Johnseye said:

 

Right.  If I incorporate a NUC as endpoint, which I'm likely to try now, I would use a 6" or 1' ethernet cable.  Likely 360 shielded.

Well 6 to 12 inches will definitely not be enough physical separation to test my theory. I thought Roy said he had 53 feet between the server and nuc. Let me know if you need a long bjc6a. I may be able to dig one up.

[lmitche]

1 hour ago, austinpop said:

 

Yes, that is correct. As background, I'd like to remind people I was a staunch supporter of the endpoint/streamer approach, and regarded the direct attach approach as inherently flawed. But in light of what I experienced with the OCXO stitch > SE > tX (with Ref 10) chain, I accepted that there was more to this than met the eye, and to follow the evidence (at least my ears), rather than my belief.

 

Ever since Roy told me of his findings with the NUC/SR-7,  I've been wanting to corroborate it in my setup, but I have never had both the NUC and SR-7 at the same time. 

• As I posted a short time ago, my experience with generic NUC and SR-4 was not as good as the Zenith SE, but it could be because I did not have eMMC and SR-7
• I too was curious why this finding did not apply to the sMS-200ultra, so I tried the experiment Roy mentioned, with the sMS-200ultra powered by the SR-7. And just as before, this did not exceed the SE.

So the working conjectures to explain Roy's findings are (let's not even call them hypotheses):

• eMMC over SSD
• Intel CPUs over ARM
• in-memory "Dream" OS (Linux based)
• SR-7 DR rail
• something about the NUC mobo.

You may want to add:

• Bridged nics in the server
• An audiophile switch with isolation between ports.
• And potentially distance between the sever and renderer. > 50 feet in Roy's case.

[Johnseye]

1 hour ago, lmitche said:

Well 6 to 12 inches will definitely not be enough physical separation to test my theory. I thought Roy said he had 53 feet between the server and nuc. Let me know if you need a long bjc6a. I may be able to dig one up.

 

So you're suggesting to test with even longer length for more possible EMI/RF interference.  I could go to about 80 to my office.  It could be a worthwhile test.

[lmitche]

11 minutes ago, Johnseye said:

 

So you're suggesting to test with even longer length for more possible EMI/RF interference.  I could go to about 80 to my office.  It could be a worthwhile test.

Yes, that would be ideal. Then of course you could move things to the nuc and test again. That would tell the story.

 

Alternatively you could power your current music server down and then use the nuc ro stream from your office pc.

 

I might try that here.

 

[lmitche]

3 hours ago, austinpop said:

 

Or native-sampler?  

Nativist is taken already.

[JohnSwenson]

7 hours ago, Johnseye said:

 

Right.  If I incorporate a NUC as endpoint, which I'm likely to try now, I would use a 6" or 1' ethernet cable.  Likely 360 shielded.

I would recommend against using such sort Ethernet cables, I have been doing a LOT of experimentation with Ethernet interfaces recently and found that many PHYs need a certain amount of capacitance on the pairs in order to work properly, a 6" cable just doesn't have enough. I had a situation where a 3ft cable worked fine, a 1ft was marginal (significant packet loss) and 6" did not work at all. I soldered some small value caps across the pairs and presto the 6" cable worked great. This tends to support the "not enough capacitance" theory.

 

So going for very short Ethernet cables may not be a good thing. I personally would not go shorter than 2ft of cable between PHYs.

 

Of course not ALL devices are going to have this problem, but I found it on a high percentage of the devices I was testing.

 

John S.

[austinpop]

2 hours ago, JohnSwenson said:

I would recommend against using such sort Ethernet cables, I have been doing a LOT of experimentation with Ethernet interfaces recently and found that many PHYs need a certain amount of capacitance on the pairs in order to work properly, a 6" cable just doesn't have enough. I had a situation where a 3ft cable worked fine, a 1ft was marginal (significant packet loss) and 6" did not work at all. I soldered some small value caps across the pairs and presto the 6" cable worked great. This tends to support the "not enough capacitance" theory.

 

So going for very short Ethernet cables may not be a good thing. I personally would not go shorter than 2ft of cable between PHYs.

 

Of course not ALL devices are going to have this problem, but I found it on a high percentage of the devices I was testing.

 

John S.

 

Guess that could be one reason why my 1.5m SOtM dCBL-Cat7 sounds so good.

[Johnseye]

3 hours ago, JohnSwenson said:

I would recommend against using such sort Ethernet cables, I have been doing a LOT of experimentation with Ethernet interfaces recently and found that many PHYs need a certain amount of capacitance on the pairs in order to work properly, a 6" cable just doesn't have enough. I had a situation where a 3ft cable worked fine, a 1ft was marginal (significant packet loss) and 6" did not work at all. I soldered some small value caps across the pairs and presto the 6" cable worked great. This tends to support the "not enough capacitance" theory.

 

So going for very short Ethernet cables may not be a good thing. I personally would not go shorter than 2ft of cable between PHYs.

 

Of course not ALL devices are going to have this problem, but I found it on a high percentage of the devices I was testing.

 

John S.

 

Very good information John.  I will take heed. 3ft ethernet it is.  Thanks!

[ElviaCaprice]

22 hours ago, romaz said:

 

No doubt that this NUC board can be further improved, Mark, but it is impressive to hear how good this thing sounds "as is."  And running an OS from memory doesn't guarantee low latency if the OS is inefficient and has lots of unnecessary processes/threads running and if inefficient drivers are being utilized.  Sometimes, the bottleneck is in software and not in hardware which is why it was interesting to see the wide range of 10-150X less latency that was reported when this OS was run from RAM vs a PCIe NVMe SSD.  Also, RAM should have way more than just 10-150X less latency than an NVMe SSD and so obviously, a well-tuned OS matters.

 

Interesting Roy, but I can't see how OS latency  has anything to do with audio stream SQ, especially if feeding a Chord DAC.  JRiver already loads the entire song to memory before playback.  The NUC mobo is being reclocked  DIY with a master clock. 

 

I agree that software needs to function properly, but other than convenience of use,  I've found that any changes in optimization for Windows 10 to not matter at all anymore on my sCLK-EX NUC. 

 

I do find a difference in some mobo noise added, if I try to power my SATA II HDD from the mobo instead of separately externally.  I prefer HDD's to SSD's.  I would think the power feed back and noise from extra memory onboard the NUC to be worse than an externally powered HDD.  

 

I could test a Linux OS operated from memory, loaded from a memory styx, but I would probably run into driver problems with the way my tXUSBexp PCIe card, as it is set up externally from an adapter on my NUC.  

 

Will be interesting to see what others hear/discover concerning latency.

[flkin]

11 hours ago, austinpop said:

 

Or native-sampler?  

 

Same-pler? ?

[hieukm]

4 minutes ago, flkin said:

 

Same-pler? ?

Hi Flkin,

 

i also have IC cables with Mumetal shielding and experience the same with yours. The speed and amount pf detials is unbelievable, bass is much tighter. However there is a problem with the treble that makes the sound not organic and digital. Do you think it will go away in time.