ADAU1787 serial port latency

Hello Jeroen,

Yes, there is a huge difference in latency between the internal ADCs and the serial port. the serial port has a max of 192kHz sampling rate. The internal ADC can run at 768kHz and be routed directly to the FASTDSP at that rate. You cannot go to the SigmaDSP at that rate, you would have to route through sample rate converters and that will add latency.

You can bypass the sampling rate converters on the serial input port but the fastest you can run the serial port is 192kHz so if you do that they the SigmaDSP or the Fast DSP will either have to run at that rate or go through an ASRC to get the incoming signal up to 768kHZ. I do not think this will give you results you will like.

If latency is key then you are really forced to use the internal converters. The serial ports have this pesky thing called physics that cause problems with running clocks and data into and out of a part on a board.

Dave T

Hi Dave,

Thanks for your reply.

I went to double check the datasheet and hardware config section. Is it correct that this 192kHz limitation of the serial ports is not mentioned anywhere directly?
Do I understand/find correctly that the limitation stems from the maximum master BCLK frequency of 24.576 MHz? If this is the case, isn't the maximum samplerate 384kHz?

Is there any (hacky) workaround that may be worth to try? For example, what about running the serial port as slave instead?

Kind regards,

Jeroen Roth

Hello Jeroen,

It is always better to have the clocks going in the same direction as the data for signal integrity and timing reasons. The signal edges are all aligned.

You are correct that the bit clock is also an issue and 24MHz is the max. So this comes into play when you are using TDM with a higher channel count. I have seen some people be cleaver and do things like combine two samples into one 192kHz frame to get 384kHz data rate but DSPs are involved and in your case the ADC will not be able to do that.

Here is a screenshot of the digital timing specs that show the 192kHz limitation.

I do not see any other workaround on this. The design of this part intended on the serial port being connected to a system processor or something like that which would run at a slower rate. The low latency path would all be internal and only the slower cancellation results analysis would use the serial port.

I have been advised that I might be using an older version of the datasheet for this information. I just asked someone from the team that is responsible for supporting this part to jump into this conversation. So expect some updates.

RevA datasheet has the serial port rate max at 768kHz so quite a difference.

Dave T

Hi Dave,

Got it.

I just checked again (in the Rev A datasheet that is currently online) and noticed the note:

BCLK for 768kHz / 16 bit would be 768kHz * (2*16 bit) = 24.576MHz. So it would make sense if BCLK is the main limitation.
Unfortunately 16 bit cannot contain enough dynamic range and 24 bit would still exceed 36Mhz.

If only this setting had another magic MONO option to do what you described

Kind regards,

Jeroen Roth

Hello Jeroen,

I have been checking internally and it looks like the serial port is rated up to 768kHz fs. But, the realist in me and with my experience with PCB layouts I am doubtful that you could actually make this work on a PCB layout. The timing is very tight with a BCLK of 24MHz. This is made worse when the BCLK and LRCLK have to come from the DSP to the ADC. The clock edge has to go out of the pin-pad, then travel over the PCB with the stray capacitance on the board then the ADC pad has to see it, process it internally to tell the data output to advance to the next bit value then send that signal to the pin-pad and then along the PCB traces then to the DSP then the DSP pin-pad has to bring it into the latch to latch it in. ALL of those steps have their own bit of latency! They all add up and you only have 20ns to get this done!!

If you can send MCLK from the DSP to the ADC and then set the ADC to be the clock master that would help. It is always best from a timing perspective to have the data and the clocks travelling in the same direction.

I wish there was a way to override pesky physics!!! It would make life a lot simpler for all of us! LOL

Dave T

Hi Dave,

I understand that it is a challenge, but it is worth it to me to atleast do further research into if it is possible (Sorry for being the stubborn engineer).

If at 768kHz a maximum of 16 bits is supported, then it isn't really of any use to me due to the limited dynamic range.
It might still be interesting to see if I can get away with 384kHz / 32 bits with reduced loopgain.
Can you maybe check if this is the correct (theoretically supported) maximum samplerate at 32 bits?

Kind regards,

Jeroen Roth