Evaluation board for an multiple-channel active noise cancelling system

Hello srick,

I can answer some of the questions.

srick said:
about 400µs to process the signal from beginning to end

The analog in to out of the EVAL-ADAU1467Z eval board is around 1.3mS at 48KHz. whereas the ADAU1787 running at 768kHz which has an analog in to analog out latency of only 5us.

srick said:
interface for 6 microphones via I2S (2 would be fine to begin with)

Both ADAU1467 and ADAU1787 can support TDM8. But remember that the ADAU1787 only has 1024 instructions per sample at 48KHz, so you may not be able to do heavy processing with all 6 channels.

srick said:
I was looking at the EVAL-ADAU1787Z board, which seems to satisfy my requirements but im not sure, as i read in a forum post here from 2019 that FxLMS is not available on the ADAU1787 without coding it from scratch. Is it supported by now?

The FxLMS is not available in ADAU1787 due to its limited processing resource. The ADAU1787 does have NLMS filter, so you can build the algorithm around it.

srick said:
Because of this i was looking into the EVAL-ADAU1467Z for the increased processing power and support for the various FxLMS algorithms, but the AD1937 featured on the board seems to be far too slow for my application.

Yes, the sigma3xx DSPs have a lot of processing power, so it supports a few adaptive filter algorithms.

The digital in to out of the sigma3xx (ADAU145x, ADAU146x) DSPs are around 6-7 samples. So, you can have a look at the low latency codecs.

We have some low latency codecs like the ADAU1372. But it is still not super low latency. But you can have a look, it goes up to 192KHz.

The DSP core, serial port can run up to 192kHz fs. so, this limits the latency.

This is just a general overview; others may chime in and comment their views.

Regards,

Harish

Hello Harish,

thank you for the quick answer! Is it correct that if I opt for the EVAL-ADAU1467Z and restrict myself to four PDM microphones for preliminary testing, I would be able to entirely bypass the ADC of the codec using either a BCLK_INx pin or a BCLK_OUTx pin, along with two of the SDATA_INx pins? Could it be that using only the DAC side of the AD1937 may be fast enough for my application?

Regards,

srick

Hello srick,

The group delay even for the DACs are still a little high. This codec was not designed for low latency.

Here is the specification:

The ADAU1372 is a low latency part. Even with the serial port and the ASRC it still is much better. Here is the specification for 48kHz fs:

You can find the graphs for 96kHz and 192kHz also in the datasheet.

I do not know how many channels you need? There are some other options. The ADAU1966A or the ADAU1962A are multi-channel DACs that have a register setting for a low-latency filter mode.

Dave T

Hello Dave,

I looked into the ADAU1372 and it seems to work for me. I only need 2 channels for a stereo speaker setup. I think im going to get the EVAL-ADAU1467Z, using the Serial Data Input either with PDM or I2S MEMS microphones, bypassing the codec on this Board, doing my processing and then pass on the data through the serial port to the ADAU1372 on its evaluation board.

Do you have any other suggestions ? Thanks for your help!

srick

Hi Dave,

I've got another question. I've managed to run my I2S microphone at 96 kHz. I'm thinking of running the Core at the same speed so I don't have to use the ASRC's and get a manageable group delay from the DAC on the evaluation board on top. Do you know if the 3072 instructions per sample are enough to run the FxLMS algorithm for one reference and error microphone? From my understanding I need roughly 4M+1 instructions/operations, where M is the number of filter taps, to run the FxLMS. So 3072 instructions per sample from the ADAU1467 should be plenty. But I don't know if I'm missing something. I've looked through the FxLMS implementation documentation in SigmaStudio, but I couldn't find anything. I haven't ordered the EVAL-ADAU1467Z yet, so I can't just try it out.

I should also have mentioned earlier that I'm still an undergraduate, so please bear with me if I miss something that should be obvious.

srick

Hello srick,

Let me see if I can help a little here.

1st, you had asked about using up to six mics and mentioned PDM or I2S mics. It looks like you pick ed up an I2S mic. This is fine for a couple of channels. If you need to have more then consider looking into using the ADAU7118 to convert up to 8 PDM mics into one TDM stream to go into the DSP. The DSP itself has four PDM mic inputs as well.

Using the ADAU7118 will have less latency because you will not be going through the ASRC of the ADAU1372 serial port. The ASRC on the serial port is super great for many applications. It really simplifies the clocking but for ANC applications as you know latency is to be avoided at all costs!

There is no way to bypass the ASRC on that part.

So if you are using the I2S microphone you already have or use the ADAU7118, either way, the DSP will be the clock master on going to the microphone(s). Since the DSP is clocking the entire thing it is super easy to just set the Core Start Pulse register to the X2 setting to run the core at 96kHz. I think you may have found that already.

Regarding instructions. I wish the programmers would have included the instruction load for that block in the Wiki help files but they did not. I expect you have found the help file? Modified FXLMS(ADAU145x) [Analog Devices Wiki]

I expect you will have no trouble running it. I just dropped it into my basic starter project, grew the reference audio inputs to two and grew the Anti-noise output to two outputs. Complied it and the report says it estimate an instruction usage of 347 instructions. It is an estimate because there are loops in the code. I expect you will have plenty of instructions to do the other things you will need in your program and run it at 96kHz. By the way, usually this is run at a lower sampling rate to save instructions and also because often the application is only for voice and there is a limit on the highest frequency you can cancel as well. (back to the latency discussion...)

Now, for running out to the DACs. This goes back to the ADAU1372 serial port having to go through an ASRC again.

I have some other suggestions but the issue is that all those parts are super small wafer level BGA packages making it difficult to use for a project board unless you are only using our evaluation boards. The ADAU1777 is very similar to the ADAU1372 but I am pretty sure you can bypass the ASRCs. The ADAU1787 that you looked at earlier you definitely can bypass the ASRC. That part also has a fast DSP and a SigmaDSP but it is a smaller and slower SigmaDSP. It is a Sigma200 core. So you could just use the ADAU1787 as a stereo DAC. For a school project that makes sense. For a product it does not. I wish we had a low latency stereo DAC but we do not. We have the ADAU1962A that is a 12 channel DAC with a low-latency mode but that is overkill for your needs.

You are doing great with your undergraduate work and research! Keep it up. You have picked up on a lot of the issues and doing a project like this will highlight some more.

Dave T

Hello Dave,

thank you for your quick and extensive reply, I very much appreciate your help and suggestions! In order to keep my solution as simple as possible (and also within a reasonable budget) I looked into the Documentation of the ADAU1467 again and on page 67 is stated: "All input channels are accessible by both the DSP core and the ASRCs." this is also backed by the wiring diagram on the same page:

So on the ADAU1467 i should be able to bypass the ASRCs entirely, since the DSP will be the clock master going to the microphone(s) and the devices should be in sync. If I stay with only the evaluation board for the ADAU1467 I will have to use the DAC from the ADAU1937. Judging from the documentation of this part there is no ASRC to worry about. (I'm assuming the ADAU1467 and 1937 on the eval board are in sync and are using the same timebase)

Latency of the microphone: ~50µs

digital in to out on the sigma3xx DSPs 6-7 samples (as Harish mentioned): ~73µs@96kHz

Group Delay on the DACs of the ADAU1937:115µs@96kHz

so in total round about 250µs which should spare enough time for serial port latencies and signal amplification for the speakers. Also my 400µs requirement was a conservative estimate to give me a little wiggle room. So I might just get away with it.

Am I missing something crucial?

I guess I should just try it because I need a sigma3xx anyway for the FxLMS algorithm. If it doesn't work I can always add another codec. Or I will have to nicely ask someone over in the EE department next door for help on a custom PCB if nothing works.

DaveThib said:
By the way, usually this is run at a lower sampling rate to save instructions and also because often the application is only for voice and there is a limit on the highest frequency you can cancel as well.

I was wondering how other people are dealing with latencies, because I kept reading that they are running their DSPs at 8kHz in comparable setups. I'm dealing with the alarm sounds of medical devices such as ventilators, patient monitors and syringe pumps which are periodically and mainly in the 500, 1k and 2k octave bands so I expect no major issues here. I was just thinking about running at 96kHz in order to combat latency not because I want to cancel super high frequencies.

srick

Hello srick,

The ADAU1467 is super flexible with routing. The ASRCs are there to use on the way into the core or on the way out of the core or not used at all. It is fully configurable.

Off the top of my head I do not know if I have a video showing how to use the ASRCs. If not then that needs to be on the list!

You are wise and correct to use higher sampling rate for the serial transfers to save on latency. Others will then in the core go to lower sampling rates now that the data has been transferred to save on instructions. You may not need to do that. Plus, they often have to pass standards that are written for 8kHz or 4kHz bandwidths.

You are correct that the group delay of the 1937 is not great but at 96kHz it is in the manageable range.

Dave T