ΣSigmaStudio Ask AI Русский Log in

S/PIDF Receiver + ADAU170x, different sample rates

SigmaDSP & SigmaStudio DanielK Apr 2, 2012 00:00 3 replies Original on forum ↗
Subscribe
DanielK Question
Apr 2, 2012 00:00

Hi,

I'm currently designing an audio system which is driven by an S/PDIF receiver. This receiver also generates the MCLK which is always 256xfs (e.g. 12.288Mhz@48kHz, 24.576@96kHz, ...). The ADAU is driven by this Clock and I've set the PLL mode pins accordingly (Mode0: 0, Mode1: 1).

Now to my question: When the sample rate of the S/PDIF signal changes I always assumed that I have to change the filter coefficents but the SR bits in the DSP Core register (0x081C) as well, e.g. if I have a 48kHz signal set them to 00 and with a 96kHz signal I would set them to 01. But after some testing it seems that I could leave the SR bits @00 and the DSP still worked fine (and my filter curves are also correct after updating the coefficients). Changing the bits to 01 doubled the corner frequency of my filters.

So why I don't have the change the SR bits?

I've read all the posts related to the sample rate but it seems I still didn't grasp the concept of the whole Clk generation. Any help here would be greatly appreciated.

Thanks!

ADIApproved Reply
Apr 2, 2012 00:00

Can you let me know if I understand the situation?

When you're receiving 48 kHz data in the S/PDIF receiver, it generates a 12.288 MHz clock and sends that to the ADAU1701. The ADAU1701's PLL is set to Mode0: 0, Mode1: 1, which is 256 x fs mode.

When you're receiving 96 kHz data in the S/PDIF receiver, it generates a 24.576 MHz clock and sends that to the ADAU1701. The ADAU1701's PLL is still set to Mode0: 0, Mode1: 1, which is 256 x fs mode.

Is that understanding correct?

DanielK Reply
Apr 3, 2012 00:00

You're right, the PLL mode pins were always set to Mode0: 0, Mode1: 1. In the meantime I've also tested it with Mode0: 1, Mode1: 1 (== 512xfs) and it worked too. I just have to change the Sample rate setting in the drop down window in the schematics tab, compile&download the code again and the filters are correct.

By the way the S/PDIF receiver is integrated in a Cirrus logic codec CS42528.

But I also read again all post regarding this topic and I think the correct way of doing the whole thing would be be something like this:

1. detect sample rate change

2. reset the DSP

3. Set the PLL Mode pins [256xfs for 44.1 & 48kHz (11,289 & 12,288 MCLK)and 512xfs for 96kHz (24,576 MCLK)]

4. reprogram the DSP to the correct settings (SR bits & filter coefficients)

It works this way but I try to avoid the whole reprogramming as this takes about 300-500ms and this delay is noticable by the user. I'm still trying to understand why it also works without changing the PLL Mode pins. If I got the Clock concept right the DSP should be either over- or underclocked if I don't change the Pins but the MCLK frequency.

ADIApproved Reply
Apr 3, 2012 00:00

Hi Daniel,

You're correct. As you probably read in that other post, setting the PLL to "X * fs" considers "fs" to be the base sample rate of the audio, which is in the 48 kHz range. The idea is that if you want to use 96 kHz mode, you simply double the rate at which new samples arrive in the DSP core, while the actual clocking in the chip remains the same.

If you're doubling the MCLK but not changing the PLL, then you're effectively overclocking the DSP core by making it run twice as fast. I would have expected this to not work - either the PLL would break down or there would be timing violations in the DSP - but I guess the design is robust enough that somehow it's working in your case. That could be particular to the individual IC you're using. Since silicon wafers have a wide tolerance during manufacturing, you might receive ICs that do not function when overclocked. I guess what I'm trying to say is that ADI guarantees that all ICs will function within the limits of the datasheet, but since you're effectively overclocking the chip past the limits in the datasheet, then we can't guarantee that it will work!

Long story short: it would be best if you do the method you mentioned in your second post, even though it takes a fraction of a second to reprogram everything.