Audio Adapter SGTL5000 Group Delay

Status
Not open for further replies.
A

aidyw

Active member
Hi,
I'm very interested to use the audio adapter (SGTL5000) in a servo control project. Having read the datasheet from cover to cover, I am still having to make a very important assumption about the CODEC's performance. I would be grateful if you could share any experience you have with it.

I need to know the group delay associated with the CODEC. The block diagrams of the sub-systems does not show any anti-alias filtering or decimation filtering, and there is no mention of associated group delays in the specifications. Can I therefore assume that the CODEC contains no such filtering?

To be specific I wish to know how long does it take to get a sample into the CODEC over I2S and for the corresponding analog conversion to be seen on the line-out. I can calculate i2s FIFO times within the MCU so this is not to be a consideration. I need to know does the unit have any internal FIFO, if so how many samples, (is it fixed), is there any digital decimation-filtering, if so what is the group delay.

For my closed loop system, group delay is utterly critical. Ideally I would like to see samples (let us say @96K) leave the MCU and that 10uS later the analog line-out reflects this sample.

Do you have any info and/or experience in this regard?

Many thanks
Aidan
 
Best is to take a look @ the Datasheet.
Lets us say samples @ 44.1K, because others are not supported by the audio - library :)
 
Frank B said:
Best is to take a look @ the Datasheet.
Lets us say samples @ 44.1K, because others are not supported by the audio - library :)
Click to expand...

Thanks, what the library supports and what the chip can do are not the same, but thanks for the heads up.
 
Thanks,
Hmm, I don't think this helps. They are talking about latency of over 6mS, this is an order of magnitude off the mark. It would make it totally useless in my application. But it's not real anyway. and I don't believe for a moment that this is related to the performance of the CODEC.

So I assume and its still n assumption, that if I disable all filtering within the the Audio Processing Block, I should have a direct switch between i2s and the DAC, so long as there is no HIDDEN filters, then latency should be approx a single sample time at whatever sample frequency is chosen. If that is 96K then it's around 10uS.

I would like to see this with my own eyes.

As an example, I curently use the TLV320AIC23B from TI. This has the following data:

The delay between the converter is a function of the sample rate. The group delays for the AIC23B are shown in the
following table. Each delay is one LR clock (1/sample rate).
Table 3−1. Group Delays
FILTER GROUP DELAY
DAC type 0 11
DAC type 1 18
DAC type 2 5
DAC type 3 5
ADC type 0 12
ADC type 1 20
ADC type 2 3
ADC type 3 6

These filters are in the signal path and can not be disabled, but they change according to the sample rate and i2S format chosen. So I have optimized for my application and have delay down to around 250uS. I am completing all my DSP routines in less than 40uS. Such a shame to then stuff 250uS extra latency in the path, simply because of the codecs FIR filters.

6mS is a huge delay in a control system and especially considering, for example, at 500Hz, we have a period of 2mS. Therefore 250uS latency represents 45deg phase lag. Dangerous indeed for a stable control system. So 6mS is totally unacceptable. I would describe closed loop control as the absolute epitome of a real time "real time" system.

So estimations and approximations are not acceptable to me. I need cold hard timing data. But thanks all for your interest and assistance.

Maybe I just get one and find out the harder way.
Regards
Aidan
 
Status
Not open for further replies.
Back
Top