Synchronization of a TLV320DAC3120

One correction - slaa469 figure 4, not figure 3!

The preferred method is to use the externally generated BCLK as the input to the PLL (assuming that the BCLK is continuous) and not use an MCLK altogether. This way it is guaranteed to be synchronized with the audio data.

Thanks. We can provide a continuous BCLK, although we need to know the acceptable jitter on it. Our audio samples are not synchronous to our local system clock (from which the BCLK would be derived), so we will still need some method of pushing/pulling BCLK to synchronize it to our incoming audio samples - this modulation of BCLK will generate some jitter. The "recovered" audio clock will have some amount of jitter. We understand that using a jittery clock will increase our THD. How much jitter can be tolerated on the DAC3120's BCLK (assuming it is selected as our internal master clock for the DSC3120) without data errors occurring?

For example.... If we were to use the TI CDCE913 as a MCLK source (it's min output freq is too high for BCLK), using the CDCE913's  VCXO to synchronize a ~10MHz clock to the incoming audio sample rate, use the DAC3120's PLL to generate BCLK and MCLK in master mode, would it be reasonable to expect the output jitter of the CDCE913 meet the  input requirements of the DAC3120?  Can you recommend a better solution?

How do you obtain your digital audio (what's the interface / data format)? Ideally you should make sure that the word clock is synchronized with the digital audio data (word clock = sampling rate frequency) and that the bit clock is continuous and also synchronized. Is there no way to derive the bit clock from your digital audio source instead of from another clock that is not synchronous? I'd be very concerned that this will cause random clicks.

The jitter should be <100ps RMS. If you elaborate on your audio source format/interface, I may be able to suggest a solution.

The audio is obtained wirelessly, through a CC2543 and transferred to the DAC3120 via the CC2543's SPI perhipheral interface. The audio is a continuous stream at 50Ksps, 24 bits per sample. WCLK is 50KHz, ACLK is 2.4MHz - both currently being output by the DAC3120. The DAC3120's MCLK is currently a 1MHz clock, derived with a hardware timer in the CC2543, and thus synchronous to the local CC2543's crystal oscillator. The DAC is setup for a 96MHz internal clock generated by the DAC's PLL.  We collect data on the phase relationship of the incoming RF frames and the outgoing SPI bus and will use the phase information for rate adaptation. There are a lot of potential solutions but none are perfect yet. We're hoping to avoid the added cost of a VCXO or additional circuitry to pull the CC2543's oscillator.

One of the potential solutions that we've tried is to update the DAC's PLL settings (R, J, D) dynamically to speed up or slow down the 96MHz clock as needed to match the incoming frame rate (since WCLK and BCLK are derived from the 96MHZ clock). This method accomplishes the goal of matching the received frame rate, but it seems the DAC's PLL is not happy being dynamically updated and the audio takes a hit each time the PLL config is updated. If there is a method of updating the DAC's PLL without glitching the internal clock, it might work.

Thanks.

Is ACLK synchronized with WCLK (it is 48x WCLK - so I assume it is). If so (and the jitter is within 100ps RMS), you can use the PLL with:

R=1, J=40, D =0, P=1

and NDAC =3 and MDAC=5, and DOSR = 128 for a sampling rate of 50kHz

Your other method won't work because you cannot tune the PLL on the fly (you have to stop the converter before changing the PLL registers).

Yes, in this configuration, BCLK (sorry about the ACLK typo!), is synchronized with WCLK. The jitter on the clocks is fine in this configuration. However, neither clock is perfectly synchronized with the incoming audio samples. The timing of the audio samples is controlled by a RF audio transmitter, on a physically remote unit. Do you understand why we don't have a local timing source synchronous to the audio samples?

I'm afraid you'll have to design this system with a synchronized clock to avoid audio artifacts. Tuning the clocks in real time with a VCO doesn't seem like a reliable solution. And as I said, you can't adjust the PLL parameters on the fly.

I'm not familiar with the CC2543 but how does this part provide the samples to the SPI? There must be _some_ clock in your receiver that is synchronized to the samples.

What information would you use to "just skip or add BCLK cycles"?

The proper way to deal with synchronization issues like that (assuming that the average rate from your receiver matches the sampling rate) in hardware is to use a FIFO that is filled by your receiver at the receiver's rate (where some samples are randomly received sooner or later by a BCLK cycle) and emptied by the DAC with the DAC generating the BCLK and WCLK.

Alternatively if the CC2543 supports this you could implement this FIFO functionality in software.