ADAU1452 Random audio phase response on PLL startup

Hello unitrobe,

I assume the phase you are measuring is the group delay between the input signal and the output signal. You are probably looking for what the delay is and if it is constant?

I also see that you are driving the DACs from the DSP.

In your schematics I saw that the MCLK that is used by the ADC is also used by the DSP which is good. I did not see the DAC in your schematic but I assume it also is running at the same rate.

So here is the issue. The LRCLK edge of the DSP and the ADC will be within a sample rate of each other, since they are both divided down from the same master clock, but the location of the edge will depend on when the internal control and calibration circuits came out of reset and the counters started dividing down the master clock. So that will be random. No way to control that. It will stay exactly the same once it starts since they are on the same master clock but no way to reset a counter to start at a different time.

So the solution is to operate the DSP and the DAC both as clock slaves fully. You are operating the serial input port as a slave but the DSP core and the DACs are operating on the internal fs clock.

Set the DSP start pulse to be the serial input port you are using. In your case that is serial input port 0. Now the core will start running the program when the LRCLK edge arrives.

Then you will have to run the ADC clocks over to the serial output ports AND send it over to the DACs. I see you have test points on serial output port 0 but you will still have to send the same clocks to the DAC so you will have to jumper them over. You cannot slave serial output port 3 to port 0 and have it send out those clocks. I wish it did that but it does not. All slaving does is to drive the internal shift registers but it does not send it out of a pin. So you have to jumper the ADC clocks to the DAC and set the DSP to slave from those clocks.

This should get rid of all the variability and leave you with a fixed group delay.

Dave T

Hello Dave,

Thanks for the detailed reply.

Yes, you assume correctly that I am seeing slight changes is the latency each time I download from SigmaStudio to the DSP.

Yes, I am driving BCLK, LRCLK, and SDA out from the DSP to the DACs.

Yes MCLK is common to all digital devices on this unit (ADC, DSP, DAC).

I know that the fix you are suggesting of slaving the DSP output clocks to the ADC will work if my ADC LRCLK was compatible with the DAC. I know this because I have done this on another design (I2S in and I2S out). The reason I tried this current configuration is the ADC is outputting TDM8 and DAC expects I2S. The TDM8 LRCLK is not compatible with the I2S DAC. I wasn't aware that the DSPs LRCLK would have random latency through each reset of the PLL. I assumed (stupidly) that the DSP would have a stable latency/group delay no matter what, otherwise the internal DSP LRCLK is of limited value.

Is there no way to sync the LRCLK edge of the DSP to an input port? I've set the DSP start pulse to be the serial input port 0 but I still have the variable latency issue when I do a "Link Compile Download". I am attaching a screen shot of this setting for clarity.

You mentioned using output port 0, I wasn't sure what you meant there. Would using the output port 0 to drive the DAC solve this issue? I can reroute anything on this prototype design. I want to get this resolved in the best, cleanest way possible. Please let me know what you suggest.

Thanks for your time.

Hello,

unitrobe and I had a lengthy exchange over email to try to solve this problem. It is a little bit of a corner case that we just could not cover easily. The solution is usually to have the output serial ports also operate as a slave. The clocks coming into the serial input port would be jumpered externally to also go to one output port. Then the output port can slave to the external clocks and the serial input port and then set the core Start Pulse to also follow the serial input port. In this case the clocks coming in were TDM clocks and the output port needed to be I2S so the bit clock frequency was wrong. All the devices were on the same master clock. So what happens is that the DSP internal PLL and clocking structure will start counting the start of the frame on a different cycle of the master clock. This means that the LRCLK out of the serial port will be locked and will not drift but the clock edge will not be exactly the same as the input frame clock. Where it is will always come up random. it will never be more than one frame off but if the application is very sensitive to the overall group delay it is a problem. If it were always the same it would not be a problem but in this case it is random. Most systems it does not matter exactly when the DAC signals are coming out, what it important is that they are locked to the same master clock so no lost data. So this was a corner case I could not solve. I did talk to a digital designer and found out that they did put in a feature to be able to reset these counters on our newer products so I guess we improve as we go along.

From our last emails I think the solution was to synthesize clocks from an external source to the DSP and send that to the serial output port.

Dave T