Importance of clocking

Spend your money on a good DAC that includes a good clock.  Spending thousands on a clock is a huge waste of money, IMHO.  

As mentioned earlier, the main purpose of an external clock is to synchronize multiple devices, not to improve sound quality. 

If there is an improvement in sound quality, it's going to be much less than you could have realized by putting your money into a great DAC.  Lipstick on a pig and all that...

The issue with S/PDIF or AES "reclockers" is that you have two clocks arguing over what should the absolute clock rate be.

The DAC is forced to take one of two approaches: Abandon it’s internal clock or attempt to keep it’s internal metronome and "fix" upstream deviations from it’s own mechanism. This is exactly the thing pro clocks do, but only because there are upstream devices manipulating the data stream. They are there to stop an inevitable argument that arises as a result of a studio’s workflow. Home users HAVE no such arguments to solve, but can create them by adding upstream clocks.

Maybe the best of these situations is to use an Asynchronous Sample Rate Converter, like in the Schiits, but then you’ve got to deal with the fact that your DAC is no longer being given bit-perfect conversions.

In measurements done, I’ve seen original DAC jitter perform actually get degraded, and the signal looks like the upstream jitter PLUS the DAC’s original jitter signature.

Either use an integrated streamer/DAC or a streamer with a multi-second buffer plus USB / asynchronous communication with the DAC is the way to go IMHO.

I should point out, use whatever you want to which sounds good to you, but so far all I'm reading is a misunderstanding of how and why studio clocks work.  I'm going to go with the documentation from Benchmark and Mytek and say it's a bad idea.

@erik_squires 

for avoiding misunderstandings: In my case Dac, Etherregen and USB reclocker are all synchronised to the same Antelope 10m clock. When using AES or SP/DIF the DAC needs to rely on the incoming embedded clock signal whereas USB asychronous slaves the server‘s clock, so effectively my server is equally synchronised to the 10m clock.

The issue with S/PDIF or AES "reclockers" is that you have two clocks arguing over what should the absolute clock rate be.

The DAC is forced to take one of two approaches: Abandon it’s internal clock or attempt to keep it’s internal metronome and "fix" upstream deviations from it’s own mechanism.

How does the DAC know? What do you mean by 'abandon it's internal clock'? Are you talking about the external clock input of a DAC substituting its internal one?   Don't you agree that the better (more accurate with less jitter/noise) the incoming data on AES/SPDIF, the easier the job of the DAC's internal clock?

@greg_f   There are two different ways of dealing with S/Pdif.  One, very common way, is to adjust D/A clock to average frequency of incoming S/Pdif stream while another is to completely ignore S/Pdif clock, strip the data and send it to D/A converter at different rate (Asynchronous Rate Converter).  

In first case data is often oversampled being sent to D/A converter in exact multiples of received frequency, while in the case of Asynchronous Rate Converter, D/A conversion frequency and incoming signal frequency are independent.  My Benchmark DAC3 D/A converter runs always at 210.9kHz - no matter what signal frequency is (it was 110kHz in DAC1).

CDP output data can be buffered and sent at exact intervals since both buffer clock and motor speed come from the same source (quartz crystal), but receiving D/A converter has to be somehow synchronized, otherwise samples may be lost.  In older devices it was Phase Lock Loop (PLL) analog circuit adjusting Voltage Controlled Oscillator (VCO) - D/A conversion clock.  These days everything is digital, so PLL circuit is also likely digital.  Either way, in this scheme D/A conversion rate is not constant, but adjusted to average frequency of incoming S/Pdif stream.