Nice that you probably don’t have to wrangle with a condo association to put up an array of dishes. I do, so a Kronos1 is not in the cards.
I’ve been happy with the OP21 but somewhat concerned with long term drift in accuracy. That along with the comments from dCS suggest that the Perf10, by design, is better in this area. And from your prior comments, it certainly has positive sonic value over the OP21. Hope I’m reading you correctly.
By the way, you did mention an issues with overly bright and obtrusive LEDs. Did you find a solution for these?
If I bring one of these in-house, I think I’ll avoid electric tape. I’ve found this solution problematic. Will try using LightDims a try. Found these dots, of varied sizes really do the job. And in the case where I need to see if a unit has been turned off, I get a little halo leakage.
One thing nice is that the folks who make the Perf10 are close by my Alameda home. Not so for Kenji over the big pond…
We all have different tastes, but in my opinion the lights aren’t the only thing on the SRS I’d want to cover up. The entire fascia is — to me — absolutely hideous. Works a treat with a Clock cable into the Vivaldi Clock though!
(I’m not sure the design brief for the dCS and SRS design teams was entirely the same, of course…)
One which is hyper accurate in the long term. Short term accuracy (jitter performance) is not as much of a concern as you aren’t clocking audio, you are clocking a clock - different requirements from that perspective. The links Greg posted should cover this topic pretty well!
That may well be true (admittedly I haven’t dug much into the specs myself) but phase noise performance is much less of a concern in this use case. It is more important when looking at a clock that is controlling audio products like a DAC where jitter performance is crucial, but in this specific case looking at a reference clock feeding something like the Vivaldi Clock, long-term accuracy is what you need over jitter performance.
The Mutec clocks would be better suited to connecting to a DAC for example than they would acting as a reference for another clock, assuming that clock has performance anything like the Vivaldi.
Appreciate the information. A recent conversation with another happy user of the Cybershaft OP21 echoes your comments. Though not a dCS customer but an Esoteric one, he also pointed out the more important factor of long term clock stability over short term for the dCS stack. I think he also noted the difference of clocking types which seem to be either Word clock versus PLL. The dCS Master clock utilizes the Word clock approach in conjunction with the DAC and Upsampler. Though not using an Esoteric master clock, it would appear that what Esoteric offers is similar to the Cybershaft.
I gather from your comments that the dCS Master is unique in its use of a global master. So, the SRS Perf10 would seem a more suitable choice for its long term accuracy rather than short term accuracy.
However, I’m still wondering how each type of clock would affect the ultimate performance and sound quality from a system incorporating a dCS stack, all other things being equal.
Cybershaft OPA21 and Mutec Ref 10 SE 120 use OXCO and emphasize on low phase noise (-120dBc/Hz @ 1Hz or better). Cybershaft does not publish any long term stability data.
Perf10 is a Rubidium atomic clock and emphasizes on long term stability. It ages considerably less than Cybershaft or Mutec.
Phase noises are given as -130dBc/Hz @ 10Hz for Perf10; -140dBc/Hz @ 10Hz for Cybershaft OPA21 and -148dBc/Hz @ 10Hz for Mutec Ref 10 SE 120.
I’m currently using Mutec Ref10 SE 120 to clock Mutec MC-3+ Smart Clock USB, which in turn will be used as wordclock for all units, which have external wordclock inputs.
Any chance to get your series of articles as a downloadable white paper in pdf format?
Yes, we are working on getting the posts organised as white papers in pdf format - so far we have the Ring DAC posts done, and are working on getting the filtering and clocking posts arranged as such as well.
@James
thanks a lot for the first PDF. I am looking forward to the other ones.
Could you please look at the quality of the diagrams? They seem unsharp, much less sharp than the text.
If for tcp based n/w interface/source the timing information from original source is anyway lost because of buffering etc, then how using an external clock (instead of Dac’s internal clock) can address that issue ?
Timing is not lost from any original source as it is in fact always imbedded within each PCM sample during the A-to-D stage. The physical media, such as a CD, is not where the original music source timing information is retained.
Once the TCP streams are decapsulated as PCM samples within the dCS platform, they’re synchronously clocked out precisely, exactly the same as all other (synchronous) inputs, and processed through to the final D-to-A conversion.
Well I made the comment based on this statement “This stage, the unpacking and buffering, effectively removes any timing link between the TCP packets and the resultant audio signal. (Read that sentence again, as it’s very important.)” which is applicable for N/W and Asynch USB sources.
That timing James is referring to is the timing associated with the reception of IP packet, from across the Internet, or even from a Compute platform over USB; Packets arrive in bursts and with a lot of jitter. The buffers within the dCS’ network board ensures that those bursts/jitter have zero impact on the quality of audio playback.
In this case, as Anup has explained below, there is no timing link between the source material and the DAC. The DAC does not have any other clock domains to worry about here, so it simply converts the audio samples from it’s buffer at it’s own rate. If there is a Master Clock in the system, this means that the DAC then has a cleaner external reference clock signal to lock to, ensuring the timing of when these samples are converted is good and reliable.
Using a Master Clock in this case does not solve any problems, but it does increase audio quality (see the Intrinsic Jitter post for details on how).