ADAU1466 T Connection Latency

Hello Carlos,

It's not possible that the T connector caused this delay. The T connector will not introduce any latency. It has to be a converter issue or source issue. The T connector is a software mechanism and it has nothing to do with physically introduce a delay.

If possible could you please tell us like how your inputs are getting into the system and what converter you are using? 

Have you tried with an oscillator input and still getting the same result? We may guess few possibilities if you give us some info on this.

Regards,

Harish

Hi Harish,

I have done several tests and I always get the same result, when I put the T connection I have a difference between the two channels.

For the A/D I use the AKM AK5552 connected to the SDATA_IN0 of the ADAU1466 (0 and 1).
For the D/A I use the AKM AK4490EQ connected to the SDATA_OUT1 of the ADAU1466. (16 and 17)

Since the ADAU1466 supports a build made for the ADAU1452 directly, I've tried the same programs but built for the ADAU1452 and it works fine.

In any case, when I use the T connection, the input does not affect the result, since before the T I have a single signal, and it should only affect the result from the T block to the DA output.

If I connect the direct input without going through the T, using the L and R channels of the AD it works correctly compiling for ADAU1452 and ADAU1466.

If I connect the input through the T connection, using only one of the input channels of the AD it works correctly compiling for ADAU1452 but when I compile it for ADAU1466 I have a difference in latency between the channels, this gives me to understand that the problem It's not from the hardware, it's something from the software.... Is this possible? Or am I wrong about something and I don't see it?

Attached the 4 projects of SigmaStudio 4.7.

Regards

Carlos

ADAU1466 Direct OK.rarADAU1466 T Connection FAIL.rarADAU1452 Direct OK.rarADAU1452 T Connection OK.rar

Hello Carlos,

Sorry for the delay in responding. I needed to draw some diagrams and have the time to explain it all. 

First, your test is actually showing you where the problem is but it takes a bit of detail to see it. 

First, it is impossible for the a "T" to introduce any delay. Here is why. Look at the diagram as you read my explanation as to why:

The serial input and output ports function as their own objects and run at their own rates. All they do is shift the data in and then deposit the data in a memory location. Or it takes the data from a memory location and shifts it out. It is up to you to setup the clocking to be correct. 

Then the core uses its "start pulse" setting to signal when to start running the program instructions. When it starts then it picks up the data from the memory address the compiler supplied the "move" instruction to pick up the data. Then in the case of the pass-thru program it simply takes the data and deposits it into a memory location that the compiler told it to put it into. This all happens during one sample period. The program always is fully executed every sample period. 

Here is a diagram of the program what uses the "T"

As you see, a "T" is not an instruction at all. A "T" costs no MIPS, what the compiler does is to simply supply the same address to the MOVE instruction that picks up the data for the left and right channels. So instead of picking up the right channel data, it picks up the same address that the left channel is using. So again, the program runs during the sample period and the same data in placed into both the left and right output memory location. Then the next sample period the serial output port picks up the data and shifts it out. There is no way the left or right can be any different in time in the core. Absolutely not possible. 

So why are you seeing the difference you might ask?

Lets talk about the serial I2S format. 

The standard I2S format uses a 50/50 duty cycle LRCLK and at the start of the frame the LRCLK goes from high to low and he left channel data is transmitted when the LRCLK is low. Then when it goes high the right channel data is transmitted. 

Look at this diagram to see what is happening: 

If the codec is set to send out the Left data when the LRCLK is high ( this is usually a setting option ) then you have the problem that the codec is placing one channel of data during one sample period and the other during the next sample period that the core is using. 

So when you only send one channel out to the DAC, the DAC is picking those two identical samples during different sample periods. It also could be the ADC side however, I think it is both. Because when you run the core to pick up the two samples, it is picking them up from two different sample periods and then depositing into two different sample periods thereby getting the data back to being in the same sample period and it measure no phase difference. But, when you break the data path in the core by using a "T" you can see the issue. Without the "T" it is obscured because it is reversed coming in and then reversed going out so it looks right. 

So look carefully at your serial port settings on the codec and in the DSP. 

This is where the setting is in the DSP

The I2S standard is the negative polarity of the LRCLK falling at the start of the frame. 

Sorry this is so long buy I felt I really needed to prove this to you. 

Dave T

Hi Harish,

Forgive me for my very late response to your help, I was with other parts of the project.

Thank you very much for the detailed answer that you have given us, it has helped me a lot to know a little more about how SigmaStudio works.

The configuration of my converters is not a standard i2s, I have it configured as Left Justified with 32bits and two channels. My problem, as you mentioned, was the configuration of the converters, I had the polarities incorrectly configured and I had not realized it.

Thanks a lot.

Regards

Carlos