Note that the 575 is advertised as the lowest phase noise crystal available “in a 5 x 7.5 mm package.” The DS uses a lower phase noise Crystek CVHD-957 - there are even lower phase noise VCXOs out there but they have a narrower pull range - to be able to deal with the 100ppm variance allowed by Redbook we need a wide range of possible frequencies and that comes at the cost of a little phase noise (tho not so much when the crystal isn’t being pulled, e.g. for the bridge or USB.) Most of the time people talk about clocks they are talking about fixed frequency clocks which, in principle, can have lower phase noise than a VCXO, but, for example the fixed frequency crystal you mention, tho very good, isn’t quite as good as the 957 even so.
Sorry for the silly question, but I’m a little bit confused: does the Crystek CVHD 957 reclock all the inbound data or it works only on usb connection?
Everything in the DS runs directly off of the 957 - the DS reclocks everything with it, but it also (carefully) uses it to track the average of the incoming sample rate and upsamples everything to a multiple of the 957 synchronously. In the case of USB the 957 is just centered and the normal USB sends the sample clock derived from the 957 to the PC and receives the samples back already almost aligned with the 957. Then, like all other inputs, the data is reclocked with the 957 to eliminate incoming jitter.
In the hardware all inputs work the same: the VCXO (957) is controlled to run at the average rate of the currently selected input. The FPGA has a big enough buffer to absorb any lead/lag between the current input rate and the current output rate (set by the VCXO.) In theory this buffering is a low pass filter on any incoming jitter - a low pass filter that rejects jitter with a higher frequency than a fraction of a Hertz. In practice nothing is perfect so the lower the noise of an input, the lower the noise of the system (if only slightly.) USB is treated like any other input except that since it already compensates for differences between the input rate and the output rate the VCXO has nothing to do.
Put more simply: things like groundloops, shielding of cables, ground noise, etc. on inputs have a much bigger effect than the specific clocks used on those inputs.
Can I please clarify. There are a few people over at the CA forums reporting great results with various combinations of the SoTM sCLK-EX board providing high quality clock inputs to various source/path components such as the SMS-200-ultra NAA and even the LAN Switch.
The theory/experience seems to be that by using the sCLK-EX they can improve & synchronize the clocks on 2 or 3 components right before the DAC and this in turn allows the DAC to perform even better. The Chord Dave has been mentioned frequently so it’s not just for lower end DACs.
Do you have a view as to whether this is worth exploring upstream of the Directstream DAC? Or do your previous comments on this thread indicate that you feel the DS clock is already doing a sufficient level of reclocking that any upstream improvements wouldn’t be likely to make much of a contribution within the DS?
Many Thanks,
Alan
PS the ultimate ‘version’ of this reclocking setup seems to be SMS-200-Ultra and LAN switch (modded) to be clocked by the sCLK-EX. And the sCLK-EX in turn connected to the Mutec Ref 10 which provides a 10 MHz clock source for all the components to use. So would an input signal to the DS that had been reclocked upstream to 10MHz be likely to improve the DS by virtue of providing a great signal or would the DS clock reclock it regardless and potentially lose the benefits of all the upstream work?
The LAN clocks aren’t related to the audio clock. Still having them synchronous with the audio clock can help: “all” of the noise comes at the same point in each clock cycle so the DAC can (in theory) stay away from those points. In practice this isn’t really what happens, but it shouldn’t hurt and can help (as long as it doesn’t add unfortunate groundloops.)
The architecture of the DS’s clock won’t allow it to synchronize too closely with an incoming clock (after all, synchronizing closely means following the jitter closely.) But if the input clocking to the DS has a narrow frequency excursion there might be small benefits.
I suspect that paying close attention to the power of the devices upstream will have similar, if not a bigger effect in a system with a DS.
So I may get to invest/waste/spend (delete as appropriate!) more money if I wanted to pursue the ‘clock’ goodness that Romaz and co are describing on CA.
Follow up question. Is using the I2S input instead of the USB input a factor in terms of whether any upstream reclocking potentially benefits the DS? i.e. does either USB or I2S potentially better transfer the reclocked goodness?
BigAlMc said
Follow up question. Is using the I2S input instead of the USB input a factor in terms of whether any upstream reclocking potentially benefits the DS? i.e. does either USB or I2S potentially better transfer the reclocked goodness?
The path is much more direct with I2S - the clock is actually there :) With USB there are 8000 packets of data every second and what's worse is that since 8000 doesn't divide 44,100 evenly the number of samples in each packet keeps jumping around. The ground on the HDMI cable we use for I2S is also substantial and the signals are well isolated and shielded - this is quite a contrast from the design of USB cables. You'll probably need a lot fewer tweaks with an I2S setup if your source supports it. Using an USB to I2S converter on the other hand may go either way.
So I have a MicroRendu providing USB to a Singxer SU-1 which converts to I2S for the DirectStream. It’s sounding pretty great as I modified it to be powered by an Uptone Audio LPS-1. But as ever in this hobby I’m wondering if there’s more!.
So I’m wondering if using an sCLK-EX to improve the clock on the USB NAA, the LAN switch and the SU-1 would result in an even better I2S signal for the DS.
Alas I guess the only way to know for sure is going to involve spending at least a couple grand and trying it out. But some users on CA are saying these tweaks provide amazing results within their systems. Hence the interest.
Thanks for the detailed and helpful feedback.
Regards,
Alan
PS One of the implications of these sCLK-EX reclocking discoveries seems to be that the LAN switch with it’s crappy cheapo clock is one of the weakest links. Perhaps worth considering for the PS Audio server / BIII that are in the works. Can that switch be bypassed or can an audiophile switch be included.
what are you using to power the microRendu ? Can you describe the improvements you noticed with adding the SU-1 in the chain ? One of my friend has the Sonore psu powering the uR and it sounds excellent with the DS and better than powering it with LPS-1. This is inline with what Ted said earlier that improving the power will make more differences than improving the upstream clock but it would be interesting to see if the SU-1 further improves things.
I’m powering the MR and the SU-1 with an LPS-1 each. I also tried an iFi Ipower but the LPS-1 was hands down better.
Haven’t tried the Sonore Signature PS as was too expensive and too big - too many boxes on my rack without a PSU that’s full size!
The SU-1 made a good improvement using the I2S. Modding the SU-1 so I could power it by the LPS-1 made it even better. Posted my experience at the time on the threads below.
One of the implications of these sCLK-EX reclocking discoveries seems to be that the LAN switch with it’s crappy cheapo clock is one of the weakest links. Perhaps worth considering for the PS Audio server / BIII that are in the works. Can that switch be bypassed or can an audiophile switch be included.
I didn’t know that the clock in a LAN switch could make a difference to sound quality. I was under the impression that the timing of data packets over a LAN was only an issue if your renderer ran out of data altogether. Perhaps I’m wrong, though.
The power supply might be an issue though. Ted seems concerned about interference coming in along any galvanic connection to a DirectStream. (The power supply is probably also putting a whole load of interference onto your mains.) I think a lot of audiophiles would be interested in a LAN switch built along audiophile principles.
How about a PS Audio LAN switch at the other end of that final ethernet cable into the back of your DirectStream? NIce, linear power supply; perhaps a transformers on the ports?
Some of it goes over my head and shouldn’t really make much of a difference (on paper at least) but the guys playing around with this over at the CA forums are finding that using the sCLK-EX on the SMS-200 makes a big difference, using the same sCLK-EX (which has 8 clock outputs I think) on the LAN switch has a further improvement and then using it on the USB bridge (the SoTM model, can’t recall which) improves it further still.
The theory (I think) is that by improving/synchronizing all three clocks in these upstream components the signal that reaches the DAC is so well clocked that it makes a big difference.
I’m not nearly technical enough to follow the intricacies of this. But the prospect of pushing the DS DAC sound quality even further into the stratosphere certainly appeals
Hence my question to Ted about whether the DS is likely to benefit or not.
And yes, I think that good PSU’s for each of these components including the switch is a given within this reclocking experiment.
Re the Audiophile LAN switch. Alex at Uptone Audio has indicated that they might build one next year. But if PS Audio or Uptone Audio built one I would definitely be in the market to buy one as soon as I could.
As far as I know devices that take a file transmitted over a LAN and turn it into an analogue audio stream don’t derive their DAC clock from or synchronise their DAC clock to the data stream coming from the LAN. I hope that anybody reading this who knows more will correct me if necessary.
I speculate that any audible differences that come from what they’re doing are a consequence of changing incoming interference rather than a consequence of having a more precise timed stream of data packets coming from the LAN.
I’m the first to admit that the science/technical theory is WAY above my head. But the experience of a few of the guys over at CA is that the SMS-200ultra (using the sCLK-EX) clock adds a big jump in SQ and that modding a LAN Switch (A. to support the sCLK-EX & B. replacing the capacitors - I think) results in a similar jump in SQ. They are experimenting with other units in this chain (including excitingly for me the Singxer SU-1 - as I own/love this unit) but they have described the duo of SMS-200ultra and modded switch as the “biggest bang for buck” in terms of reclocking.
The capacitor mods in the switch are a contributory factor no doubt.
In laymans terms for the likes of me that isn’t very technical, a switch costs what, 20 bucks. So it isn’t really that surprising that replacing the cheapo clock & caps with better ones leads to an improvement.
Like yourself I’d welcome any more technical input of why this might be.
BigAlMc said
but they have described the duo of SMS-200ultra and modded switch as the "biggest bang for buck" in terms of reclocking.
Hi Alan, I've been following that thread. There's a few guys there that really have tried everything under the sun and it's so great that they share their experiences. It's fascinating reading (for me anyway). This took a turn just recently when romaz said he now prefers the direct USB connection, not going over the network ! So it's appeared to have gone full circle, at least for him and maybe a couple others. But a tonne of knowledge has been learnt and graciously shared along the way.
I think it’s a case of watch this space because there will be more developments in that thread, no doubt.
Another thing to note though, is romaz appears to have a USB input DAC (a stellar one at that) but no ethernet input. I wonder how he would go if the Chord Dave had an ethernet input and he could by-pass USB along the way (like we can with the Bridge II). We’ll never know I guess.
Still, I find all of his observations fascinating.