is this a valid way of synchronizing two USB DACs?

[MCH]

It has been discussed here millions of times: you can't just use various USB DACs simultaneously to have a multichannel system because they are not synchronized and will drift apart.

But yesterday watching the last video at eevblog, where he talks about crystal oscillators, he mentions what most of you knew but i didn't: that the way crystal input pins are built, there is an inverter between the XI and XO pins. You could change the crystal between those pins for a crystal oscillator connected to the input pin and use the inverted signal from the feedback XO pin, now unused, to drive other devices, that would be, obviously, synchronized to the first...

I got curious and asked in the video comments section, Dave himself answered:

There are plenty of not so old DAC chips that have XI/XO pins, for instance the ESS 9038Q2M, ES8928 etc or the ES9038PRO inside the Topping DM7 (which i believe uses a quartz crystal). Is Dave right and one could mod regular stereo DACs to have a perfectly synchronized multichannel system? or get two DM7 to have 16 synchronized channels?

PS: this is out of pure curiosity, i am not planning to do any of this myself.

 

[FERCSA]

Of course it's working. Sometimes I use a frequency generator to substitute an oscillator or crystal for a microcontroller or other digital ICs. Just make sure your DIY clock generator or any clock source can handle the load. You can do that with an oscilloscope. It's necessary to check because higher load can deform the waveform.

I had plans to add an clock input to my D90SE and get a second unit but instead I got a good deal on a used DM7. Since then I moved to a 3 way active speaker setup so DM7 was a good choice and also more cost effective anyways.

 

[restorer-john]

Is Dave right and one could mod regular stereo DACs to have a perfectly synchronized multichannel system?

They won't be perfectly synchronized. Let's assume the TCXO on the 1st DAC is immediately adjacent to the DAC itself. How do you propose to get the clock signal to the 2nd DAC with inherent propagation/transmission delay in the coax? You'd need a master external clock and matched cable length external clock inputs or a delay line on the 1st DAC to compensate. Even then, you wouldn't get sample accurate sync.

 

[Hayabusa]

In this way the two sample clocks would not drift. But there would be a delay between the sample clocks that starts arbitrary every time you would power up the system.
The only way to get them in sync is to also connect a word sync and the clock and have a circuit comparing both word syncs and insert and gate out clock pulse until they are in sync. This would be accurate accurate to one clock period of the xtal oscillator

 

[MCH]

Ah... that makes sense. Thank you for yous answers.
Yes I didn't choose the right words, wanted to say that they don't drift, not that they are perfectly synchronized, but I missed they won't be word synchronized.
And if the two dacs are up and running the moment we start the playback, will that fixed delay still be relevant in terms of home audio? I mean, can that be long enough that a tone at 20kHz drifts significantly? Or are we talking nanoseconds?

 

[JSmith]

It has been discussed here millions of times: you can't just use various USB DACs simultaneously to have a multichannel system because they are not synchronized and will drift apart.

I suppose one could use a multi-channel DAC such as;

Okto Research

Objective performance

www.oktoresearch.com

JSmith

 

[voodooless]

They won't be perfectly synchronized. Let's assume the TCXO on the 1st DAC is immediately adjacent to the DAC itself. How do you propose to get the clock signal to the 2nd DAC with inherent propagation/transmission delay in the coax? You'd need a master external clock and matched cable length external clock inputs or a delay line on the 1st DAC to compensate. Even then, you wouldn't get sample accurate sync.

At near speed of light propagation through the wire, I would not be too worried about the delay. I highly doubt that one would recommend same length speaker wire because of the delay it causes…though there may be other reasons like equal resistance, which is irrelevant in case of clocks. Line impedance however will be of interest to make sure the clock can be transferred cleanly.

You’ll need more than 6 meters of wire to cause a 1 cycle difference at 44.1 kHz sampling. That equivalent to less than 8 micrometer of sound though air difference. Your head is jitterier than that

 

[radix]

I thought the ESS chips use something like a 100 Mhz oscillator. If the XO is a 100 MHz square wave, you likely need 500 MHz of bandwidth on the cable. Not sure what it would be for a clipped sine wave. Anyway, I would expect the main issue to be HF loss. Maybe LMR-100 cable would be OK for a short run? But I suspect the main issue is the chip drive capacity and making sure the impedances are OK.

 

[KSTR]

I thought the ESS chips use something like a 100 Mhz oscillator.

In async mode (where the chip resamples the I2S, not matter where it came from), 100Mhz and 50Mhz clocks can be used.
In sync mode, 22/24Mhz is fine, too, and which is not that difficult to transfer with a coax or differential twisted pair. At any rate is must be the oscillator the USB bridge is running on.

But as others have mentioned to @MCH, the actual problem is high chances for arbitrary delay which could amount to many 10's or 100's of microseconds.
There is no way to precisely sync the two playback start processes.

 

[Keith_W]

Clock sync'ing multiple USB DAC's isn't your only problem. How are you going to feed signal to the multiple DAC's? Windows can not send output to more than one audio device at a time. I am not sure about Mac and Linux.

It would be much easier to use something like a RME Digiface USB. It presents itself as a single device to Windows, and handles the routing to multiple DAC's internally. Because USB is synchronous, all the DAC's take the clock signal from the Digiface.

 

[KSTR]

To add, even the ADI-2 Pro, a device designed to explicitly run two (or more) in sync in a master-slave config with SPDIF used as the clock source for the slaves, cannot guarantee sync is always the same within a +-1 sample offset range, and basically unknown subsample offset.

 

[KSTR]

Clock sync'ing multiple USB DAC's isn't your only problem. How are you going to feed signal to the multiple DAC's? Windows can not send output to more than one audio device at a time. I am not sure about Mac and Linux.

That depends on the drivers. RME's ASIO driver for ADI-2 Pro etc can handle several devices (of the same type) as one cluster.

 

[MCH]

In async mode (where the chip resamples the I2S, not matter where it came from), 100Mhz and 50Mhz clocks can be used.
In sync mode, 22/24Mhz is fine, too, and which is not that difficult to transfer with a coax or differential twisted pair. At any rate is must be the oscillator the USB bridge is running on.

But as others have mentioned to @MCH, the actual problem is high chances for arbitrary delay which could amount to many 10's or 100's of microseconds.
There is no way to precisely sync the two playback start processes.

Could Mac aggregate device do something useful in this case? It does have a clock drift correction setting, seems that it doesn't work as well as having the dacs oscillator connected would, but it must be getting some feedback from the DAC somehow, maybe it can deal with proper word synchronization too?
(again, just curious, not trying to solve anything)

 

[voodooless]

the actual problem is high chances for arbitrary delay which could amount to many 10's or 100's of microseconds.

How? The signals travel at about 95% of the speed of light. You'll need some serious lengths of wire to get to 10 microseconds, let alone 100...

 

[KSTR]

How? The signals travel at about 95% of the speed of light. You'll need some serious lengths of wire to get to 10 microseconds, let alone 100...

Protocol-related, buffering, all that kind of stuff, nothing low-level electrical of course.

 

[voodooless]

Protocol-related, buffering, all that kind of stuff, nothing low-level electrical of course.

I would expect that two of the same USB devices will not have significantly different propagation times. Having the OS resample multiple devices to use them together also works fine (at least on MacOS). I would not expect major issues when not doing this and using a master clock to subs them up. The pro-audio world has used this for decades..

 

[KSTR]

The pro-audio world has used this for decades..

... but have always advised to never split (2 or multi-channel) stereo channel feeds across several word-clocked devices exactly because of the variable micro-delays.

 

[restorer-john]

The pro-audio world has used this for decades..

Word clocks and DAC clocks are quite different.

The OP asked about using the onboard clock in one DAC to feed another DAC. That clock will be 50-100MHz. At that speed, everything matters as I said in my previous post.

He won't get sample accurate, syncronised DACs unless they on the same PCB with identical length clock lines from the TCXO/Oscillator.

 

[voodooless]

... but have always advised to never split (2 or multi-channel) stereo channel feeds across several word-clocked devices exactly because of the variable micro-delays.

Those can be compensated for, however. Especially in an active system, where you have one DAC for L and the other for R, it really should not be a major issue. Otherwise moving your head would also be..

He won't get sample accurate, syncronised DACs unless they on the same PCB with identical length clock lines from the TCXO/Oscillator.

No, but the differences would be so small, it's inconsequential, I gave the calculations already... The argument of @KSTR that the rest of the components give you a much higher difference in potential propagation is a much more compelling argument. And yes, transferring a 50 to 100 MHz signal isn't easy, but that's beside the point.

I'm not saying it's the best idea in the world, but as a compromise, it could certainly work.

 

[MCH]

guys,
I was not very convinced about the concept and practical difference that word clock would make vs master clock, at least for home audio applications, so i went and ask a member more knowledgeable than me, that pulled up this extract from the RME fireface 800 manual. This is what @MC_RME explains (bold highlight is mine):

24.2 Technical Description and Usage

In the analog domain one can connect any device to another device, a synchronization is not necessary. Digital audio is different. It uses a clock, the sample frequency. The signal can only be processed and transmitted when all participating devices share the same clock. If not, the signal will suffer from wrong samples, distortion, crackle sounds and drop outs.

AES/EBU, SPDIF and ADAT are self-clocking, an additional word clock connection in principle isn't necessary. But when using more than one device simultaneously problems are likely to happen. For example any self-clocking will not work in a loop cabling, when there is no 'master' (main clock) inside the loop. Additionally the clock of all participating devices has to be syn- chronous. This is often impossible with devices limited to playback, for example CD players, as these have no SPDIF input, thus can't use the self clocking technique as clock reference.

In a digital studio synchronisation is maintained by connecting all devices to a central sync source. For example the mixing desk works as master and sends a reference signal, the word clock, to all other devices. Of course this will only work as long as all other devices are equipped with a word clock or sync input, thus being able to work as slave (some professional CD players indeed have a word clock input). Then all devices get the same clock and will work in every possible combination with each other.

Remember that a digital system can only have one master! If the Fireface's clock mode is set to 'Master', all other devices must be set to ‘Slave’.

But word clock is not only the 'great problem solver', it also has some disadvantages. The word clock is based on a fraction of the really needed clock. For example SPDIF: 44.1 kHz word clock (a simple square wave signal) has to be multiplied by 256 inside the device using a spe- cial PLL (to about 11.2 MHz). This signal then replaces the one from the quartz crystal. Big disadvantage: because of the high multiplication factor the reconstructed clock will have great deviations called jitter. The jitter of a word clock is typically 15 times higher as when using a quartz based clock.

The end of these problems should have been the so called Superclock, which uses 256 times the word clock frequency. This equals the internal quartz frequency, so no PLL for multiplying is needed and the clock can be used directly. But reality was different, the Superclock proved to be much more critical than word clock. A square wave signal of 11 MHz distributed to several devices - this simply means to fight with high frequency technology. Reflections, cable quality, capacitive loads - at 44.1 kHz these factors may be ignored, at 11 MHz they are the end of the clock network. Additionally it was found that a PLL not only generates jitter, but also rejects disturbances. The slow PLL works like a filter for induced and modulated frequencies above several kHz. As the Superclock is used without any filtering such a kind of jitter and noise suppression is missing.

The actual end of these problems is offered by the SteadyClock technology of the Fireface 800. Combining the advantages of modern and fastest digital technology with analog filter techniques, re-gaining a low jitter clock signal of 22 MHz from a slow word clock of 44.1 kHz is no problem anymore. Additionally, jitter on the input signal is highly rejected, so that even in real world usage the re-gained clock signal is of highest quality.

Do i understand correctly that a word clock used to synchronize devices is just a slower and more convenient way to actually share a master clock, and that no actual "word synchronization" or "sample synchronization" is taking place? If this is the case, if one can achieve sharing the oscillator as proposed in post #1, would that be in fact equivalent to word clock synchronization?