Is a master clock needed?

[voodooless]

I read this often here but still struggle to understand it. Anyone care to explain or link to where it is explained? Thanks a lot!

It's really simple: the ADC has its own clock that it uses to sample the data. That data is then fed with that sample rate to the DSP using SPDIF. The SPDIF carries the ADC clock to the receiver.

The DSP itself has its own clock that it works on. So to make this work with the ADC data, you'll need to asynchronously resample the ADC data to the DSP clock. From the DSP clock you can basically directly clock the DAC's over SPDIF.

 

[antcollinet]

I read this often here but still struggle to understand it. Anyone care to explain or link to where it is explained? Thanks a lot!

A separate ADC will have it's own clock. Lets say it is set to sample at 48KHz nominal sample rate (same as the minidsp DSP clock). So you'd think there would be no problem. But every clock has a tolerance, so it might be 48002Hz on the ADC, and 47.997Hz on the mini dsp (typically the tolerance would be much lower than this, but the effect is the same).

The ADC data would be clocked into a buffer at the higher rate, and clocked out of the buffer into the DSP at the lower rate. The result would be that the buffer would fill up, and samples would have to be dropped from the input stream, causing distortion in the sound. If the mismatch were the other way round the buffer would empty, and samples from the input would have to be used twice sometimes - again, distortion.

Instead the mini dsp will use a process called asyncronous sample rate conversion (asrc) to convert the incomoing samples to the same clock used by the DSP. This will not only correct for clock tolerance, but allow for conversion from different sample rates (eg 44.1Khz or 96Khz etc) to the 48Khz used by the mini dsp.

see

Sample-rate conversion - Wikipedia

en.wikipedia.org

for more info

 

[MCH]

It's really simple: the ADC has its own clock that it uses to sample the data. That data is then fed with that sample rate to the DSP using SPDIF. The SPDIF carries the ADC clock to the receiver.

The DSP itself has its own clock that it works on. So to make this work with the ADC data, you'll need to asynchronously resample the ADC data to the DSP clock. From the DSP clock you can basically directly clock the DAC's over SPDIF.

Thanks, that sounds reasonable, but the same problem would apply to any spdif signal fed to the DSP, wouldn't it?
The DSPs i know of/use -basically minidsp and camilladsp, i believe both can resample so this would be a non issue in my case (?)
Edit: thanks @tonycollinet for further explanation, just had not seen it until i posted this

 

[theREALdotnet]

It's really simple: the ADC has its own clock that it uses to sample the data. That data is then fed with that sample rate to the DSP using SPDIF. The SPDIF carries the ADC clock to the receiver.

The DSP itself has its own clock that it works on. So to make this work with the ADC data, you'll need to asynchronously resample the ADC data to the DSP clock. From the DSP clock you can basically directly clock the DAC's over SPDIF.

But with digital devices in a processing chain (e.g. ADC > DSP > DAC) there is no need to operate on the same clock beat *, hence no clock syncing is required. Each device will read from a buffer that was filled by the device before it. It will read the buffer using its own clock. Resampling is only required if the sample rates are different between devices, but even that is no biggie.

With multiple devices sharing the processing in parallel, i.e. each doing separate channels of the signal, synchronised clocks are a must, because the channels must come together in perfect timing when they hit their respective transducers.

* except in AV, where the delays brought about by buffering can be problematic

 

[Music1969]

The application is for a friend of mine who has a system configured like this:

- Turntable --> Phono stage --> ADC
- ADC --> MiniDSP
- MiniDSP --> 3 Topping DAC's --> rest of the system

No problem with up to 4 Topping DACs - 8 channels supported
And you have galvanic isolation of TOSlink

 

[rydna]

To add to that slighlty. The dacs will remain in sync, but if you want them also to have the same delay, the dacs should be identical.

Different dacs would likely have different PLL buffer depths which would result in a different latency through them. Sound through one would be time shifted with respect to the other.

So if I have 3x identical DACs (Topping E30s) fed from my miniDSP 'nanoDIGI' ... being the same, there will be no latency difference between them?

So the DACs will all:

• have the same latency
• and they will be in sync?

Thanks,

 

[voodooless]

But with digital devices in a processing chain (e.g. ADC > DSP > DAC) there is no need to operate on the same clock beat *, hence no clock syncing is required. Each device will read from a buffer that was filled by the device before it. It will read the buffer using its own clock. Resampling is only required if the sample rates are different between devices, but even that is no biggie.

No, you'll always need resampling if your clock sources are different, even if that is just a new ppm's. You'll run into all kinds of nasty shit if you don't

With multiple devices sharing the processing in parallel, i.e. each doing separate channels of the signal, synchronised clocks are a must, because the channels must come together in perfect timing when they hit their respective transducers.

But that's not what's happening here: the DSP is a monolithic block doing all the processing at once. If you would have multiple DSPs, then clock sync would be needed if you want to avoid another ASRC.

 

[AudioJester]

Yes, I think he was aware of that. Something about Icecast. I couldn't really understand what he was saying, but then I wasn't really paying attention.



They do? What solution is that?

BTW if I wanted to, I also have a solution for multichannel active setups with analogue inputs. I have an RME Fireface UC, which is what I use for my 8 channel active system with digital crossover. It has an ADC, 8 DAC outputs, mic preamp, and several digital inputs. It was quite pricey, about USD$1400. Though probably not as pricey as what Merging would charge (I know, I also have Merging in my system).

Yeah, I use similar - RME Babyface (the old original one) and an okto8 for my active setup. There are even cheaper ways to do it.

 

[rydna]

But with digital devices in a processing chain (e.g. ADC > DSP > DAC) there is no need to operate on the same clock beat *, hence no clock syncing is required. Each device will read from a buffer that was filled by the device before it. It will read the buffer using its own clock. Resampling is only required if the sample rates are different between devices, but even that is no biggie.

With multiple devices sharing the processing in parallel, i.e. each doing separate channels of the signal, synchronised clocks are a must, because the channels must come together in perfect timing when they hit their respective transducers.

OK - so are you saying that even though I have 3x identical DACs (Topping E30s) ... as they are fed from a miniDSP 'nanoDIGI' ... I do need to synchronise their clocks? (Yes, I can see how "the channels must come together in perfect timing".)

In which case - what device do I need to put between the nanoDIGI and the 3x Topping DACs?

Thanks,

 

[theREALdotnet]

OK - so are you saying that even though I have 3x identical DACs (Topping E30s) ... as they are fed from a miniDSP 'nanoDIGI' ... I do need to synchronise their clocks?

Yes, but connecting them to the MiniDSP via S/PDIF takes care of that. The situation would be different if instead of a MiniDSP you had a computer running your DSP (like I do) and the DACs were connected via USB. The computer would have to do drift compensation then (via resampling, as @voodooless pointed out).

 

[rydna]

Yes, but connecting them to the MiniDSP via S/PDIF takes care of that. The situation would be different if instead of a MiniDSP you had a computer running your DSP (like I do) and the DACs were connected via USB. The computer would have to do drift compensation then (via resampling, as @voodooless pointed out).

Aah, great! Thank you for that info.

 

[AudioJester]

By the way look up rooPlay and roon extensions to get vinyl playback through roon. Obviously still need an adc device

 

[thecheapseats]

However, in more elaborate and expansive systems, where there are several A‑Ds and lots of other digital outboard, it's often more convenient and practical to have a centralised master clock source, and to distribute clocks from that to all of the other devices, all of which are configured as slaves. All master clock units provide numerous word clock outputs, and often several AES11 clocks too (AES11 is basically a silent AES3 signal, intended specifically for clocking purposes). In this kind of system, though, it would be worth ensuring that the A‑D converters all work well when operating on external clocks, to maximise their audio quality.

The only situation where a dedicated master clock unit is truly essential is in systems that have to work with, or alongside, video, such as in music-for-picture and audio‑for‑video post‑production applications. It's necessary here because there must be a specific integer number of samples in every video picture‑frame period, and to achieve that, the audio sample rate has to be synchronised to the picture frame rate. The only practical way to achieve that is to use a master clock generator that is itself sync'ed to an external video reference, or which generates a video reference signal to which video equipment can be sync'ed.

imo, it would be silly for your friend to invest in a master clock for personal rips - like I said - just my opinion... do people do it? -sure - why?- who the heck knows? - because they can ? - it's a hobby for some...

I would ask what is the intended benefit/result of your friend doing that?... only they can answer that...

master clocks have come a long way since the advent of digital audio... it all comes down to ppm resolution... having retired two rubidium clocks over my career I'm glad they have improved... I still use a master clock because I must...

early applications of slaving everything digital and analog (ad/da/vtr/atr/midi/timecode generators) has roots because a gearbox was necessary - therefore a distributed master clock (see my next paragraph)... certainly digital systems on pro gear have drastically improved their clock resolution over the last four decades... I have no idea if clock accuracy advances have migrated to consumer digital devices... intentionally leaving dsp aspects aside for purposes of this comment...

the most notable (and accurate) is the last paragraph I've quoted above from your comment... in the 1980s when post-production often simultaneously used two or three analog multitrack machines, early DAWs while synching to video tape (29.970628 fps in the u.s.)- or 24 or 25 frames for film - all at the same time - there was a real necessity for a distributed master clock - principally to preserve the even-integer relationship of a 48kHz sample rate so it could resolve to the frame-edge of a video frame, or film frame... this is a very simplistic description of what was required to avoid sync-trainwrecks that might occur by getting some element wrong in the process...

 

[thecheapseats]

and being the old man in the crowd - I just gotta' ask ->> why would you need three dacs pushed from the same 2ch source at the same time?... (what am I missing - whole house dacs?)... I don't get it...

 

[voodooless]

and being the old man in the crowd - I just gotta' ask ->> why would you need three dacs pushed from the same 2ch source at the same time?... (what am I missing - whole house dacs?)... I don't get it...

Active 3-way or 2-way with two subs...

 

[Ricardus]

- Clock drift in 60 seconds = 6ms
- Clock drift in 1 minute = 360ms

Ummmm...

 

[thecheapseats]

Active 3-way or 2-way with two subs...

thanks - ok got it... makes sense with applied dsp and tweakerage ... I figured it was something outside of my experience realm being a 40+ year user of klein+hummel (now neumann) monitors...

and just a comment - if I were going to try something like that - I wouldn't trust two or more dacs that were not locked to a master clock... but I'm old... and one of the reasons I joined ASR...

 

[digitalfrost]

The application is for a friend of mine who has a system configured like this:

- Turntable --> Phono stage --> ADC
- ADC --> MiniDSP
- MiniDSP --> 3 Topping DAC's --> rest of the system

I pretty much run something like this.

Phone pre -> Focusrite Scarlett 2i2 -> PC
PC -> RME Digiface USB
RME Digiface USB -> 2x Topping D50

DSP is done in the PC. This works to listen to vinyl with DSP correctly applied. The only issue is if you want to measure the system because of clock drift. I bought a Behringer ADAT8200 to get a clock synchronized signal into the Digiface - you simply select your mic input as clock source.

Mixing different USB devices will always lead to clock drift, but for me it's only a problem when actually measuring the system. Vinyl playback is fine. Some measurement systems like Audiolense can compensate for clock drift, but most don't.

 

[voodooless]

I wouldn't trust two or more dacs that were not locked to a master clock... but I'm old... and one of the reasons I joined ASR...

But they are, they are clocked by the SPDIF interface.

You joined ASR because your old? Curious reason

 

[thecheapseats]

But they are, they are clocked by the SPDIF interface.

I get that - downstream clocked by upstream... the reliance on the downstream device resolving to the upstream sync is a non-issue (with assumptions) -> that (1) the upstream clock tolerances are within some steady-state limits, and (2) the downstream device can resolve the upstream's sync without issue... I know what it's supposed to do - the question is, "does it actually do it"?... in my business there's an old sync-saying, "you can drive a truck thru the gap between a few milli or micro-seconds"...

the plethora of downstream devices which were actually designed to lock to 'some' master distributed clock (pro gear) was pretty pathetic for a number of decades (and some still exist today) - these devices exhibit less jitter running stand alone than when they're externally clocked... as for the origin 'clocks' themselves - is it 47,999kHz or 48,001kHz? -or what? - who the heck knows? - unless you have the gear to check it...

one would think it to be a non-issue in 2023 - but occasionally I still get pro-tools stems to work on that are simply horrible in origin... some sound like a bowl of rice krispies was mixed in at -40db - others that are digital 'smear' (avoiding the real 's' word)...

You joined ASR because your old? Curious reason

curious reason? - heck yeah - curious till I'm cold and dead... I want to assemble a small personal music listening system (something I haven't had in decades) that sounds great but doesn't puke and die after several months in service... we'll see how that goes...