Syncing a V3 Word Clock output with a DMIC-20 AES REF input

[Chuck]

I sent out another e-mail, to Mike at Graham Patten, asking for clarification.

Gee, I wish I had the thing here, so I could just try it, to see if it works...

[Jamos]

Just read through every post in this thread...

From the GP literature, it does appear that Gratefulphish is right, in that they say the DMIC will strip the audio out of an AES (or SP/DIF) signal and just lock onto the sampling frequency.  It doesn't say anything specifically about the clock.

Since both the folks at Grace and the GP tech say using the SP/DIF will be fine, I'd guess that when the DMIC locks onto the incoming signal it also locks onto the clock.  Since it needs to stay locked, it must use the host's clock to keep receiving to frequency info.

Seem right to anyone else?

[Chuck]

This is what I sent in my last e-mail:

Mike:

Thank you, again, for the quick response.
I have been talking this over with some colleagues and we need some clarification.
Will connecting the S/PDIF output from the Lunatec V3 to the AES input on the DMIC-20 lock the DMIC-20 to the V3 clock?
We want the digital output to the recorders from both devices to be in perfect sync, with no clock drift, so the resulting audio files can be edited together later.
Some are saying that they think sending the S/PDIF out to the DMIC-20 will just set the DMIC-20 to the same sample rate and bit rate, not lock the clocks together.

Thanks again for your assistance,
Chuck

I will post the response when I get it.

[trajhip2000]

I was about to reply that locking onto the sampling frequency is the same as locking onto the clock, but I guess it's possible that it could do the former and not the latter. However, it would seem a little silly to do the former and not the latter, since you could just select the sampling freq anyways - I guess it would make sense if you wanted to use some weird sampling freq that is not one of the std presets, but that must be so infrequent that I don't see why you'd design a piece of gear like this to do that. So I still believe that it will sync to the V3 signal, but I guess that should be counted as opinion and not fact at this point

[Todd R]

Maybe this is why Gratefulphish and I do not seem to be on the same page.  It's been awhile since I reviewed the spdif and AES standard, but it's my understanding that the sampling rate and the clock are essentially one in the same.  The sample rate is twice the clock rate, but the exact clocking information can be very easily generated from the sampling frequency.  By locking to the sampling frequency of the AES reference (the V3), the DMic will be inherently locked to its clock.

[Todd R]

Oops, beaten to the punch. 

[Chuck]

So, will my e-mail question get the answer I need?

[gratefulphish]

I was about to reply that locking onto the sampling frequency is the same as locking onto the clock, but I guess it's possible that it could do the former and not the latter. However, it would seem a little silly to do the former and not the latter, since you could just select the sampling freq anyways - I guess it would make sense if you wanted to use some weird sampling freq that is not one of the std presets, but that must be so infrequent that I don't see why you'd design a piece of gear like this to do that. So I still believe that it will sync to the V3 signal, but I guess that should be counted as opinion and not fact at this point

First, as I read it, the DMIC-20, is only twenty bit, no matter what the incoming signal is.  Nothing is going to make it 16 or 24 bit.  Second, the sample rate on the DMICs are fixed.  You can buy a 44.1 or a 48 KHz DMIC-24, but they are otherwise not selectable, except apparantly, by using the AES input, which seems to only lock the sample rate, at between 30-50 KHz.  As far as I can tell, this is like DAT decks synching up, and automatically adjusting the the sample rate of the lead deck.  If wordclock was in all signals, and were as easy to send and synch, then why don't we see it on anything but the most high-end gear?  And from what I have seen, the wordclock in/outputs are dedicated solely to the clock function, and the audio signal is sent through another cable.  Let's wait to see the response to the second e-mail, which appears to clarify what is being asked.  Actually, the first e-mail had the question right, I just think that GP's response was a non-answer.

[Todd R]

So, will my e-mail question get the answer I need?

Yes, it should.  Plus soon enough you can just test it.  This part of your question might confuse GP a bit (or at least it does me):

Some are saying that they think sending the S/PDIF out to the DMIC-20 will just set the DMIC-20 to the same sample rate and bit rate, not lock the clocks together.

Are you differentiating between sample rate and bit rate, they seem like they'd be the same thing.  Or are you talking about bit depth?  The bit depth and sample rate/clocking info have nothing to do with one another.

Each data "word" in the SPDIF and AES standard are defined as to what data is in what bit place.  As part of this, there are bits in the word set aside for the 24-bit audio info or the 16-bit audio info.  This is exclusive of the clock timing.  So the AES ref input on the DMic is only going to give you clocking timing (though how it works is yet to be determined), it will have nothing to do with bit depth.  (Though maybe that's not what you're getting at with bit rate.)

[Todd R]

First, as I read it, the DMIC-20, is only twenty bit, no matter what the incoming signal is.  Nothing is going to make it 16 or 24 bit.  Second, the sample rate on the DMICs are fixed.  You can buy a 44.1 or a 48 KHz DMIC-24, but they are otherwise not selectable, except apparantly, by using the AES input, which seems to only lock the sample rate, at between 30-50 KHz.  As far as I can tell, this is like DAT decks synching up, and automatically adjusting the the sample rate of the lead deck.  If wordclock was in all signals, and were as easy to send and synch, then why don't we see it on anything but the most high-end gear?  And from what I have seen, the wordclock in/outputs are dedicated solely to the clock function, and the audio signal is sent through another cable.  Let's wait to see the response to the second e-mail, which appears to clarify what is being asked.  Actually, the first e-mail had the question right, I just think that GP's response was a non-answer.

Yep, agreed about not being able to make the DMic have a bit depth other than 20 bits.  But as I mentioned above, bit depth has really nothing to do with syncing up two sources and using a common clock.  You can sync up two sources perfectly and still be syncing up 44,100 words per second (x2 sources) and still be syncing up nothing but garbage.  That is, there are some inherent problems with recording a 20bit stream with a 16bit recorder (that will truncate the extra bits), but that won't affect the ability to sync up the two sources.  It's just that one source will have truncation errors in it, and those truncation errors (some report hearing strident highs and a fatiguing sound with truncated sources) will be carried into the merged 4ch mix.

As to the other, I don't think that the AES ref input is anything like 2 DAT decks syncing up on sampling frequency.  In that latter case, both decks are using their own internal clocks to clock the 44,100 samples per second.  The DMic AES ref input from their description seems to create the clock timing from the AES/spdif data stream.

[gratefulphish]

Todd, I hear what you are saying, and quite frankly the bit depth issue alone would make me think about doing this at all, even if the clocks could by synched.  But I went back and read the manual sections that I quoted in some of the prior posts, and everything refers to synching frequencies (as opposed to the fixed frequency of the DMIC) and there is not one single word about clock speed (pun sort of intended).  Only Graham Patten knows for sure, hopefully.  Let's wait and see how they respond.

[Chuck]

So, will my e-mail question get the answer I need?

Yes, it should.  Plus soon enough you can just test it.  This part of your question might confuse GP a bit (or at least it does me):

Some are saying that they think sending the S/PDIF out to the DMIC-20 will just set the DMIC-20 to the same sample rate and bit rate, not lock the clocks together.

Are you differentiating between sample rate and bit rate, they seem like they'd be the same thing.  Or are you talking about bit depth?  The bit depth and sample rate/clocking info have nothing to do with one another.

Each data "word" in the SPDIF and AES standard are defined as to what data is in what bit place.  As part of this, there are bits in the word set aside for the 24-bit audio info or the 16-bit audio info.  This is exclusive of the clock timing.  So the AES ref input on the DMic is only going to give you clocking timing (though how it works is yet to be determined), it will have nothing to do with bit depth.  (Though maybe that's not what you're getting at with bit rate.)

Yeah, that last sentence, on my e-mail, was an unfortunate after thought...
When most folks use the DMIC-20 the last 4 bits are truncated when recording to 16 bit, and no one complained about it then. Do you guys really think this will be an issue? I'm hoping the DMIC sends out essentially the same signal that the V3 does when they "sync" up.

[trajhip2000]

The differences in word length won't matter operationally, if the input word length is above what the input receiver can handle then the extra bits will be truncated. Whether they matter or not sonically is open to debate I guess. Truncation isn't ideal, but usually for live recordings the noise floor is high enough that I wouldn't consider it a big issue. Altho the DMIC-20 is spec'd at 20 bit, iirc the actual resolution is something below that due to the noise floor (you could check this on the spec sheet, just divide the dynamic range by 6 to get the resolution in bits (i.e. true 16 bit has 96 dB, 20 bit 120 dB, etc). I was told by G-P when I talked to them years ago that the noise floor in the DMC-20 is high enough that it acts as kind of a pseudo-dither and that you're getting something pretty close to 16 bits of resolution on the output, so in this case I think the possible sonic penalty is relatively minor.

Steve

[Todd R]

Yep, Steve's got it right there.  There is some debate about the sonic impact of truncating, esp from 24 bits to 16 bits.  But the noise level in the venue might make that moot.  And I've seen stuff from both Denecke re: the AD20 and RME Audio re one of their former A/Ds saying the same thing that Steve said the G-P guys told them.

Remember, essentially all dither is doing is adding noise to the LSB of the dithered word (eg, the 16th) so that it is random when the lost 4 or 8 bits are stripped off.  If the inherent noise of the A/D is such that that 16th LSB is already random, then an actual dither function would not be needed.  I guess the same should hold true if the noise of the audio being recorded in the venue makes that LSB random, the same should hold true, though I've never really thought of it that way.

[trajhip2000]

Cranesong actually sells something they call an analog dither cd: http://www.cranesong.com/analogdither.html Presumably somewhat more sophisticated than crowd noise, but the same general idea I think. As long as the "dither" noise isn't correlated with the audio you're recording (another way of saying you want the LSB to be random) it will function in much the same way.

Steve