Non os reclocking, I2S and DEM reclocking

[Zodiac]

A question for all the quartz heads out there...

1)

I want to install a reclocking circuit in my TDA1541 based non-oversampling DAC. The DAC is fed via a CS8412 SPDIF receiver.

From what I have read, I think that I can use any frequency for the reclocker as long as it is synchronous, i.e. multiples of both bitclock and wordclock.

In non o/s operation, bitclock is 64 * wordclock or 2.8224 Mhz. So I could use 2.8224, 5.6448, 8.4672, 11.2896, etc as the frequency for the reclocker. Is this correct?

2)

I am also thinking of going I2S direct using some LVDS transmitters and drivers. My transport runs off a 22.5792 clock. Will there be any problems using the reclocking circuit at, say, 11.2896 with the transport?

Is it also true that if I wish to implement I2S then I should send the clock signal back from the reclocker in the DAC to the transport?

3)

Re DEM reclocking. Why do you use 4*wordclock or 8*wordclock in the non o/s application rather than just wordclock?

Thanks!

Nyal

 

[Elso Kwak]

Questions for Quartz Heads

Hi Zodiac,
This one is for Rbroer as I am only into asynchronous reclocking and have no experience with DEM reclocking.
And I would like to add Rudolf is not a quartzhead.

 

[rah]

1)

From what I have read, I think that I can use any frequency for the reclocker as long as it is synchronous, i.e. multiples of both bitclock and wordclock.

You have the wrong idea about synchronous clocks. Just because the clock frequency is a multiple or is the same as the other clock, doesn’t mean it’s synchronized with it.

You have to send the clock signal from your transport...

2)
Which takes me to your next question..
You can place the clock either in the transport or the DAC and send it to the other, but the signal to the DAC is more critical so placing it in the DAC and sending to the transport is a better idea.

3)
Because the active divider inside the TDA1541A needs a higher clock than Fs to function. See Fig 1. in the TDA1541A datasheet, and look at how the DEM reclocking circuit replaces the capacitor based oscillator.

 

[Zodiac]

Re: Re: Non os reclocking, I2S and DEM reclocking

1)

You have the wrong idea about synchronous clocks. Just because the clock frequency is a multiple or is the same as the other clock, doesn’t mean it’s synchronized with it.

You have to send the clock signal from your transport...

I am aware that the clock signal is sent from the transport. In my current setup, the signal travels via the SPDIF line to the CS8412, which regenerates the clock signals. In a non os application BCK is 64Fs. Many schematics online then reclock this at 256Fs.

Synchronous reclocking, then, is reclocking at multiples of Fs (WS). Asynchronous reclocking is reclocking at other frequencies not divisible exactly by Fs such as 80mhz or 100mhz, as per Elso's reclocker.

2)
Which takes me to your next question..
You can place the clock either in the transport or the DAC and send it to the other, but the signal to the DAC is more critical so placing it in the DAC and sending to the transport is a better idea.

I will be putting the clock in the DAC, right next to the D/A chip. If I have a CS8412 in my dac, and use SPDIF as the tranmission medium, I do not NEED to have a clock link from the DAC to the transport. From what I understand implementing such a clock link will effectively synchronize the dac and transport.

I am going to do this reclocking thing in two parts.

1) get it up and running in the DAC from the regenerated clock provided by CS8412

2) get rid of the CS8412 and use I2S direct from transport to DAC.

I could implement the reclocking in the DAC in 1) at 256 Fs, as many have done before e.g. dddac 2003. That should not be an issue

In 2) however, my transport runs at 512Fs. So presumably I will either need to use a 512 Fs clock in the dac for reclocking, or I will need to in some way double the 256 Fs clock used for reclocking before sending it back to the transport....Is this correct?

3)
Because the active divider inside the TDA1541A needs a higher clock than Fs to function. See Fig 1. in the TDA1541A datasheet, and look at how the DEM reclocking circuit replaces the capacitor based oscillator.

I will look into this....

Thanks for looking at my post!

 

[ZERS]

A question for all the quartz heads out there...

1)

I want to install a reclocking circuit in my TDA1541 based non-oversampling DAC. The DAC is fed via a CS8412 SPDIF receiver.

Hi Zodiac,

what is the aim of such a reclocking ? Is it because you're fedding your dac via a CS8412 receiver ?

 

[Zodiac]

Zers,

The aim of the reclocking is to reduce jitter as at present the TDA1541 D/A chip is fed from the recovered clock generated by the PLL circuit of the CS8412

 

[rah]

Re: Re: Re: Non os reclocking, I2S and DEM reclocking

Synchronous reclocking, then, is reclocking at multiples of Fs (WS). Asynchronous reclocking is reclocking at other frequencies not divisible exactly by Fs such as 80mhz or 100mhz, as per Elso's reclocker.

No, you missed my point. Synchronous reclocking, is reclocking by a clock signal that is synchronized with the data clock.

Two separate clocks (either at the same frequency or at a multiple) are not synchronized. For them to be synchronized, not only do the have to run at the same frequency (could also be multiples), they have to be locked in phase. This is typically done with a PLL, which (broadly speaking) fine tunes the second clock until they are locked in phase.

I will be putting the clock in the DAC, right next to the D/A chip. If I have a CS8412 in my dac, and use SPDIF as the tranmission medium, I do not NEED to have a clock link from the DAC to the transport. From what I understand implementing such a clock link will effectively synchronize the dac and transport.

Yes it synchronizes them, ie. same phase, same frequency (not a multiple in this case). The CS8412 will provide you with a reconstruction of the clock in the transport, this will not be synchronized with your other clock, clocking the DAC, even if they are the same frequency (or multiple). Cause they won't be in phase. Effectively, it'll be asynchronous re-clocking.

however, my transport runs at 512Fs. So presumably I will either need to use a 512 Fs clock in the dac for reclocking, or I will need to in some way double the 256 Fs clock used for reclocking before sending it back to the transport....Is this correct?

What you wanna do is, place a low jitter clock at 512Fs near your DAC, and use a counter to divide by 2, get 256Fs and send it to your DAC. Send the 512Fs from the clock to the transport.

 

[rah]

Come to think of it, why do you need 256Fs to the DAC?

If you're looking at the DEM re-clocking circuit, then it's ok to
feed the D-F/F with 512Fs where it says 256Fs...
(will need to adjust the divider on that circuit though)

 

[ZERS]

Zers,

The aim of the reclocking is to reduce jitter as at present the TDA1541 D/A chip is fed from the recovered clock generated by the PLL circuit of the CS8412

OK
As far as I'm concerned, I plan to use the TDA chips onto an internal DAC for a DIY CD Player. I'll use the I2S signal and not the S/PIDF one. In such a case, I don't think that reclocking the signal will improve anything.

What's your opinion on that point ?

 

[rah]

Clocks in transports aren't that good. It's not only the medium/format that you use to connect your DAC, it also depends on the source of the clock from which those signals derive. The clock in your transport will typically be an inverter gate crystal oscillator, between all the noise of the other logic chips in your transport, running off the same supply. Best to place a good clock in your DAC and send back the signal.

 

[ZERS]

Clocks in transports aren't that good. It's not only the medium/format that you use to connect your DAC, it also depends on the source of the clock from which those signals derive. The clock in your transport will typically be an inverter gate crystal oscillator, between all the noise of the other logic chips in your transport, running off the same supply. Best to place a good clock in your DAC and send back the signal.

my drive will be the famous philips CDPRO2. I've read elsewhere that his clock is quite good and provides low jitter.

Should I add a third-part clock anyway

 

[Zodiac]

Rah,

Thanks for your input , I think I understand now.... there are a number of ways to do reclocking...

1) Use a free running oscillator in the DAC, use frequency divider to send Fs and 64Fs frequencies to the CS8412, effectively synchronising the clocks.

This type of implementation can be seen in the dddac

2) Use a free running oscillator in the DAC, use clock link from DAC to transport to synchronise the two clocks then reclock separately.

This type of implementation can be seen in peufeu's dac

3) Use a low jitter PLL with the CS8412 such as that designed by Guido Tent, available commercially as the XO-DAC.

4) Use asynchronous type reclocking such as Elso's reclocker.

If I then took the CS8412 out of the equation and went I2S direct using a buffer type scheme then option 2) above would be the implementation to go for

One more thing. I was looking on the web and it seems like the only readily available & cheap low jitter clocks run at 256 Fs (e.g. Guido's XO module). Is there any such thing as a frequency multiplier, a bit like a frequency divider? What is the part #

Also, do you know of a VHC version of the 4040 binary counter?

Thanks for all help!

Nyal

 

[Zodiac]

my drive will be the famous philips CDPRO2. I've read elsewhere that his clock is quite good and provides low jitter.

Should I add a third-part clock anyway

I seem to recall a topic on replacing the clock in the CDPRO with a low jitter one. I think it was BrianGT...

 

[rah]

Zodiac,

One more thing. I was looking on the web and it seems like the only readily available & cheap low jitter clocks run at 256 Fs (e.g. Guido's XO module). Is there any such thing as a frequency multiplier, a bit like a frequency divider? What is the part #

Yes there are such things as frequency multipliers, but they are complex circuits that have to be designed for the application, they involve a frequency divider (yes) and a PLL...

However even if you made one of these the, the jitter on the output will be higher than the original clock, they reconstruct (a bit like the CS8412 does) the higher frequency clock multiple
using a PLL.

Guido's XO module comes in a 1024Fs clock speed, use that and a 74VHC161 (from memory) to get 512Fs and 256Fs...

Also, do you know of a VHC version of the 4040 binary counter?

I know there is one, you could use 2x74VHC161.

Currenly my DSL is down, and will be for a week and I'm using my work dial-up network. This thing is so slow that I can't get images to load! So, I can't look at datasheets to give you the exact part number.. look for something like the 74VHC161 but with 8 bits.