Latency in Sigma DSP


Hi Team!

I have a doubt regarding how much is the system latency in ADAU1452/ADAU1467 .This is not to be confused with the processor latency which could be the time it takes for data to traverse  from input to output (lets say we call that processing latency) but if i were at all to peruse the latency that is a sheer contribution from the system (be it the interrupt initialization or things that are automatically taken care of either at run time or compile time )

How can one find out the total overall latency (system +processing ) and what would be a feasible way to do this ???

I understand that this would vary since different projects could involve different latency values at the systems end ..

Would appreciate if this could be calculated and shown with the simplest example project below


  • 0
    •  Super User 
    on Nov 22, 2019 12:21 AM


         Since your diagram includes only an oscillator and an output cell, I'm assuming you wish to know how long we must wait to see an output at startup.  I tried measuring this by programming a ADAU1452 to self-boot a program like yours.  The photo below shows that once power is applied (top trace), output begins about 400 mS later.  During this time the chip comes out of reset, its PLL stabilizes, it reads the E2PROM, it gets initialized and commences running the program.  

          Continued below... (I've discovered the hard way that this forum doesn't like long posts with multiple pictures).

  • +1
    •  Super User 
    on Nov 22, 2019 12:45 AM in reply to KJBob

    Now let's assume that the DSP is already running and we wish to measure the latency between an external event and the audio output.  For example, below an Aux ADC input gates the oscillator:

    I measured 650 uS between a signal at the Aux ADC input before the output gates ON:

    Most of this delay is from the AD1938 codec's DAC interpolation filter (521 uS at 48K sample rate).  The rest is likely the time the Aux ADC takes to respond -- its lowpass filter is designed to minimizes glitches coming from typical control inputs such as pots.  The -1938 codec's ADC anti-aliasing filter has its own latency of 479 uS, so the total analog audio-in, analog-out latency of the -1452 & -1938 system is about 1 mS.

         SigmaDSPs are streaming audio processors which execute your entire schematic (program) within the interval between one sample and the next.  A schematic too large to fit within this time frame simply won't compile.   Thus the DSP's latency depends upon  program elements which span across multiple samples, such as delays (obviously).  Filter latency is often expressed as group delay which appears much like that of an analog filter.

         Hope this helps -- I'm not sure if I understand your question fully or if it's beyond my ability to answer.

         Best regards,


  • Thanks Bob ..That was really enlightening and i appreciate the effort you put in bringing this ...However as you said that you measured 400 ms for the time it took the system to come alive is there by any chance a way to know the split up of this 400 ms delay i mean like which part of the arcaned system initialization conribute to how much delay .. And will this 400 ms remain constant our case we used an oscillator to the output but should my program grow in complexity does this latency value still hold true or will it vary?If yes then what would be the contributing factor to this variable value

    Your assistance in this regard will be highly appreciated!

    Once again Thanks a ton!

  • 0
    •  Analog Employees 
    on Nov 22, 2019 4:10 PM in reply to FormerMember

    Hello annihilate_123,

    If you are talking about the delays of getting data into and out of the part using the serial ports and going thru the core then this post will answer your question.

    The 400ms delay that KJBob had detailed so well is mostly for the self boot time. This is somewhat variable depending on a lot of factors and many are in your control.

    Using I2C is slower

    Using SPI is faster but then you have to set up the speed. So this is in your control. 

    There are some posts where I had detailed all this in very much detail. Some of it made it into the Rev D datasheet that was updated last year. 

    The SPI speed is limited by the master clock frequency when selfbooting for a short amount of time. The DSP will read in 16 bytes of data at this slow speed. In this block of data is the configuration for the PLL and for the SPI/I2C speed. Once the PLL locks then the part comes up to full speed and starts loading in the program and register settings. So the rest of the boot time is in your control to some extent. Then the length of time depends on the program size and the framework options like clearing unused RAM. Once this is all done the program start running and then there is no more delay except for the throughput delays mentioned in the post I gave you the link to.

    Many automotive companies have been interested in all these details because there are specifications for how fast audio must be heard when the ignition switch is turned on. But I don't think this is what you are interested in.

    Dave T 

  • Thanks Dave I understand what you said .


    1.In the above 400ms delay, detailed above was i2C used or SPI ?

    2.Secondly ,since this was done for SIgma 300 and as mentioned the codec was found to be the predominant factor to latency contribution can we infer that sigma350 would also produce similar results if the processing latency is ignored and only total system latency is taken into account.