Synchronizaton with World Clock or I2S input ?

[percy]

When you slave a device using a Word Clock input, or are using an I2S input, assuming that the slaved device doesn't need to 'convert' the clock to another frequency internally(like 128Fs, 256Fs), then does the slaved device still use PLL or something to synchronize the device's clock to the incoming clock signals ? or does it use the actual input clock signal(s) "as-is" as a direct substitute of the device's clock ?

With a Word Clock input, I'd imagine it would still need to do something to generate the serial clock ?

[Iain McNeill]

the names 128Fs and 256Fs relate the master clock to the sampling frequency. Many codecs have digital filters hardwired in to improve noise rating and antialias artifacts. These need to run at a much higher clock than the bit clock which will be either 16*2*Fs or 24*2*Fs or whatever.

This master clock defines the "actual" sample rate.
For instance if your master clock in a 128Fs DAC is 11.3MHz (instead of 11.2896MHz) then you actual sample rate will be 44.14KS/s. Everything will be 0.1% high in pitch.

So the slave DAC just runs to the master clock MCLK, from which are divided the BCLK and LRCLK. As long as it's within limits it'll just output what you tell it to with whatever precision you provide. Obviously, if you try and drive it at 12.8KHz master clock for a subwoofer at Fs=400Hz things will probably break down

[percy]

thanks, but still looking for the answer to my question -

Its really more of an implementation level question - Does the device use the input word clock, or clock lines on the i2s input, to synchronize itself ? or is there no synchronization whatsover and those signals are used as actual clock signals as if they were generated by a resident clock ?

[Iain McNeill]

Sorry, missed the exit there

In slave mode, most DACs I've worked with look for the host to supply MCLK,BCLK and LRCLK. In master mode then an applied MCLK will cause BCLK and LRCLK to be output on their respective pins.

BCLK, LRCLK and the data itself all must be synchronous. They cannot be derived from different master clocks. The synchronization is embedded in these signals.

[rfbrw]

Pro gear uses a PLL to synchronize the device.

[percy]

Thanks. Thats the type of answer I was looking for.

Now does that apply to both - World clock input and I2S input ?

since you specifically mentioned 'Pro gear', are there other situations in which this may not be true ?

[rfbrw]

Just Wordclock. It is a standardized interface. I2S/MSBJ/LSBJ/EIAJ etc are meant for board level connections. Use out of the box is on a manufacturer by manufacturer basis

[dmills]

Wordclock and the LRCLOCK of IIS are (apart from some electrical differences), basically the same thing.

What typically happens is that word clock (if present) is used to lock up the 128 or 256Fs clock needed my most modern DAC chips, with the LRCLOCK & BCLK being taken from the interface receiver.

It is worth noting that as far as jitter is concerned, it is mainly jitter on the 128 or 256 times Fs master clock that matters, jitter on the LRCLK is (unless really gross) irrelevant.

Regards, Dan.

[rfbrw]

Originally posted by dmills
with the LRCLOCK & BCLK being taken from the interface receiver.

Not so, that would defeat the object of the exercise.

[dmills]

Word clock might have a defined phase relationship with LRCLK for I2S, but IIRC if the converter is running left justified the Left and Right channels are reversed with respect to the LRCLK (I also recall a one BCLK offset)?

Given the several BCLK latency inherent in the digital audio receiver and transmitter chips, it is entirely reasonable that the recovered I2S or LJ digital audio have an MCLK which has an arbitrary (but hopefully constant) offset from the LRCLK at the sending end (which is buffered to produce the work clock), I would certainly not rely on the received word clock and the recovered LRCLK being in any particular phase relationship (It would be nice if they reliably were, as it would make several things easier, especially in multiple IO systems).

Regards, Dan.