• State
  • Locked Locked
  • Replies 12 replies
  • Subscribers 31 subscribers
  • Views 495 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TLV320AIC3104: Variance in SAI to DAC delay

Luke Evans
Prodigy 10 points
Part Number: TLV320AIC3104
Other Parts Discussed in Thread: TAC5112

Tool/software:

Hello,

I am looking to use the TLV320AIC3104 Codec for a communications system requiring some precise timing. I am sending 16-bit audio data (containing a sine wave) to the Codec via I2S from a processor, using a high-quality clock source for SAI.

I am using an oscilloscope to measure the delay between the first edge on the I2S serial data line and the first sine wave peak on the DAC output. I am seeing an inconsistent response time: the delay between the first serial data and the first analog peak varies ±17µs between test runs. The data sheet mentions the DAC typical group delay time as 21/fs, but does not present information about the min or max we can expect.

My application requires ±1.5µs reliability or better. The total length of the delay is irrelevant (within reason - a few ms perhaps), as long as it is consistent within this fine range. I have tried various register settings with no luck. I have also confirmed that my I2S Word and Bit clocks are well synchronized with the Data line.

What I2S to DAC delay variance should we expect, and can you suggest configuration to have the TLV320AIC3104 provide better timing precision than what I am seeing?

If not, could you suggest similar parts that may provide the reliability we require?

Thanks.

  • 0
    TI__Expert 7730 points

    Hi Luke,

    Let me check on this and get back to you by this week.

    In the meantime, can you clarify on the method used to check the delay? Is it basically delay between the MSB bit toggling on the data line and the peak of the sine wave?

    Thanks and Regards,

    Lakshmi Narasimhan

  • 0 in reply to Lakshmi Narasimhan Badrinarayanan
    Prodigy 10 points

    Hi Lakshmi,

    Thanks for the response. Yes, I am measuring the time between the first rising edge I see on the Data line when the I2S transfer begins and the first peak of the sine wave. To help make my results easier to read I am not sending a pure sine wave, but am beginning the transfer with a sample of 0xFFFF to make the beginning easier to read on my scope.

  • 0 in reply to Luke Evans
    TI__Mastermind 46615 points

    Hi Luke,

    Lakshmi is out of office until Monday so I'll contribute here.

    What is your sample rate? I have seen some variance can occur within a sample (which 17us sounds about the width depending on if I2S clocks are present when the device powers up or not. I don't think this variance is tested but Lakshmi has better proximity to the test engineers/designers to find out.

    Best regards,
    Jeff McPherson

  • 0 in reply to Jeff McPherson
    Prodigy 10 points

    Hi Jeff,

    The sample rate is 48kHz. I have the I2S clocks not present when the Codec boots for the first time, and start when my I2S transfers begin. I had tried enabling the clocks ahead of time, but that seemed to give me worse variance than starting them when the I2C transfer starts (32µs variance).

  • 0 in reply to Luke Evans
    TI__Mastermind 46615 points

    Hi Luke,

    On the layout side, is the clock routing symmetrical among all the devices? Is it possible to measure if there's any time difference between when the clocks arrives at the different pins? 

    Best regards,
    Jeff McPherson

  • 0 in reply to Jeff McPherson
    Prodigy 10 points

    Hi Jeff,

    Any clock discrepancy difference between my CPU master and the codec is in single-digit nanoseconds, if any.

    Luke

  • 0 in reply to Luke Evans
    TI__Expert 7730 points

    Hi Luke,

    Can you share the following information on this test?

    1) What is the frequency of the MCLK given to the device? Is the MCLK always active?

    2) You have mentioned that the I2S clocks are provided after the Codec boots up. Is there any delay in providing the DAC data after providing the I2S clocks, or is it given as soon as the first I2S frame is provided?

    3) When you say the variation is up to +/-17us from run-to-run, is it always discrete (either 0, +17us or -17us) or is it more distributed?

    Thanks and Regards,

    Lakshmi Narasimhan

  • 0 in reply to Lakshmi Narasimhan Badrinarayanan
    Prodigy 10 points

    Hi Lakshmi,

    1) I am using the STM32 HAL to configure and generate the clocks. The MCLK is currently running non-stop (i.e. is present at boot), and is measured with a period of 12.38 MHz on the scope. I recall trying this before, but I'll try starting and stopping this clock rather than have it run non-stop and see if that makes a difference.

    2) I am using the STM32 HAL to begin my I2S transfer. It starts the clocks and data transfer at the same time. The clock start time is very consistent. I've measured about 20ns of variability (discrete) in the time between the first WCLK edge and the first data bit, which does not seem to have any correlation with the delay I am observing at the analog output.

    3) This was an error in my original post, my apologies. It should read "17µs variability", not ±17µs. This time is not discrete. The delay is distributed randomly within a total range of about 17us.

  • 0 in reply to Luke Evans
    TI__Expert 7730 points

    Hi Luke,

    Thanks for clarifying on these queries. I will try to replicate this observation and follow-up on the same this week.

    Thanks and Regards,

    Lakshmi Narasimhan

  • 0 in reply to Lakshmi Narasimhan Badrinarayanan
    Prodigy 10 points

    Hi Lakshmi,

    Have you had any luck with this?

    Luke

  • 0 in reply to Luke Evans
    TI__Expert 7730 points

    Hi Luke,

    Sorry for the delay, and thank you for your patience on this issue.

    I am still trying to reproduce this issue on the AIC3104EVM. I am also working on measuring the same parameter with an alternate codec (TAC5112) which might be a better fit. I will provide you an update on my observations on both parts by the end of next week.

    Thanks and Regards,

    Lakshmi Narasimhan

  • 0 in reply to Lakshmi Narasimhan Badrinarayanan
    TI__Expert 7730 points

    Hi Luke,

    I set up the AIC3104EVM with I2S clocks and tried to replicate similar measurements on the same.

    I connected the I2S and analog line output signals to a mixed-signal scope and measured the delay from start of I2S data to start of analog output.

    Upon repeating this measurement multiple times, I saw much lesser variation in the delay from measurement to measurement than what you have mentioned (I was seeing around +/-2usec variation).

    One thing to note on my setup was that the I2S data itself comes after the clocks, so is it possible to check on your setup as well if the delay is consistent for such an input (similar to how you mentioned making the first sample as FFFF, can we also pad a few samples of 0000 at the beginning of the audio sample file)?

    Thanks and Regards,

    Lakshmi Narasimhan