Importance of clocking

Buffering is not a recipe for avoiding jitter.

Yes, it is.  With asynchronous USB data is delivered in packets (frames) to buffer at some time intervals, for instance 1ms - for instance 44 samples,   DAC delivers each sample to D/A converter in exact intervals (cannot be improved) signaling back buffer over/under flow.  Problem of data coming at different or uneven intervals is eliminated by the buffer and back signaling.  Synchronizing time of the frame delivery with D/A clock won’t help because D/A converter already operates at exactly even intervals.

In case of SPdif buffering in DAC won’t help because without back signaling data night be coming too fast or too slow.  It can be fixed by reclocking or most often to adjust D/A conversion rate to average rate of incoming data.

What might help with asynchronous USB is isolation that prevents injection of electrical noise from computer to DAC.   Reclocking has nothing to do with improvement but people buy it likely because it sounds promising.

What about the clock accuracy releasing the buffer, then?
 

It is internal DAC’s clock that is unaffected by any external activity (asynchronous).  DAC uses this clock to take sample of the data from the buffer and convert it to voltage at exact intervals.

It does not matter if this internal clock is inaccurate.  We cannot detect if music plays tiny fraction of percent slower or faster, but we can hear when this clock is jittery because uneven D/A conversions intervals add additional frequencies to audio signal.    We likely cannot hear jitter artifacts when jitter is below about 50ps (peak to peak) so names like “femtosecond clock” are nonsense.
 

Releasing a dirty stream to the D/A increases its processing

No it doesn’t, latency has nothing to do with it and buffers are never “underutilized” because of back signaling.

Perhaps example will help:

Worker (DAC) has to place items on conveyer belt (D/A Converter) of some machine in exactly one second spacing, but another worker (computer) hands them too slow or too fast creating uneven space between them.  Remedy for that would be shelf with many items on it (buffer).  One worker adds bunch of them (frame) to the shelf every so often and the other places items on conveyer belt in even intervals, yelling back “get more (or less) next time” to keep decent amount of them on the shelf (back signaling).

@antigrunge2 What processor?  The only one that can affect timing of D/A converter is in the DAC.  It loads samples from the buffer into D/A converter at even time intervals.  It also signals back when buffer is too empty or too full. 

Sending asynchronous data in packets is reducing stress on receiving end allowing receiver to get data in the required or convenient time.

 

AFAIK there is no error correction with asynchronous USB.  Frames contain checksum (CRC field), but I’m not sure if computer resends the frame.  In plain USB transfers device on receiving end sends back “negative acknowledge” (NAK) and frame is resent.  

Asynchronous USB is reclocker.  Placing another reclocker in front of reclocker won’t do anything.   Perhaps these devices were initially intended for synchronous or adaptive audio USB.  Asynchronous USB came later.  Another benefit is electrical isolation from noisy computer.  Reducing electrical noise injected into audio device is always good.  If your reclocker is improving sound by doing this then it is worth the money.

Let‘s just say that my ears and reputable designers like Innuos, Esoteric et al disagree with you

Disagree with what?  I don’t question you can hear the difference, but I attribute it to electrical isolation that device brings and not the reclocking process itself.

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

@greg_f I remember that Weiss DACs had Firewire. I had Firewire HDs with my old Mac computer and used them with the newer generation with an adapter. Advantage of Firewire was that it had, being extension bus, sustained bandwidth. Peripheral buses like USB don’t have that running under protocol. This sustained bandwidth made it very popular in Audio/Video industry. The great feature of Firewire - Direct Memory Access (DMA) killed it. Once somebody made pocket Linux to run on the phone it made it dangerous. Hackers could connect it to portal in large company and bypass (or even obtain password).

You can try it. Other than that you have only choice of coax or Toslink. I use Toslink because of my DAC’s very strong jitter suppression to avoid electrical noise injection and possible ground loops. On the negative side Toslink drivers have slow edges making it noise susceptible (noise on the edge modifies threshold point affecting timing). Toslink works better when system is clean of electrical noise. Faster edges of coax are less sensitive to noise but create another problem - reflections from characteristic impedance boundary. You need to use impedance matched cables possibly 1.5m or 2m long (to make first reflection miss original edge) or very short cable, Rule of thumb is that transmission line effects (reflections) start when propagation time one way is longer than 1/8 of transition time. For typical 25ns transition 1/8 is about 3ns making it 0.6m cable (assuming 5ns/m). Since it includes all wiring inside on both ends I wouldn’t go further than a foot. The shorter the better. As for the conversion from USB - that might be good, especially if it contains electrical isolation.

@greg_f   I forgot that it is specific Audio USB and Firewire.  AES seems to be the best choice.

@greg_f   You can try USB to Firewire adaptor (or cable).  They are about $5 on Amazon - might work.