How to tune AEC on XU316

[littlefool]

Hello everyone,
I'm currently working on a product design based on the XU316. While comparing the AEC (Acoustic Echo Cancellation) performance of the XU316 and XVF3800, I've noticed a significant difference between the two. I'm not very familiar with AEC algorithm tuning. Does anyone know how to tune the AEC parameters of the XU316 (I'm using sln_voice v2.3.0) to make its AEC more aggressive and achieve cleaner filtering?

Here are the spectrums of my AEC test results:



Thanks in advance for your help.
JY

[upav]

We don't currently have any docs on AEC tuning, I'm afraid.
However, looking at the screenshot you've sent, it looks like your reference signal and the mic signal are not synced.
With the time-aligned inputs, we would expect AEC to suppress around 27 dB.

Also, apart from the AEC, 3800 has an additional non-linear echo suppression, which will make it better in some cases.

Hope it helps,

[littlefool]

We don't currently have any docs on AEC tuning, I'm afraid.
However, looking at the screenshot you've sent, it looks like your reference signal and the mic signal are not synced.
With the time-aligned inputs, we would expect AEC to suppress around 27 dB.

Also, apart from the AEC, 3800 has an additional non-linear echo suppression, which will make it better in some cases.

Hope it helps,

Thank you for your quick reply. I'd like to add some details - I'm running example_ffva_ua_adec_altarch on XU316. How can I test if the reference signal and mic signal are synchronized? If there is actually a delay between them, what could be causing it?

Thanks,
JY

[upav]

I'm not super familiar with the codebase, but looking at it, there are a few configs you can give to cmake to manipulate your signal flow, this may provide you with a way to view your inputs
https://github.com/xmos/sln_voice/blob/ ... a.cmake#L4

I don't know what things can cause the mismatch between signals as it's not my area of expertise, but there are a few things I found you can play with:
reference delay: https://github.com/xmos/sln_voice/blob/ ... _dsp.h#L23
mic/reference delay: https://github.com/xmos/sln_voice/blob/ ... onf.h#L114

Not really sure why there are 2 ways to change the reference delay, and whether they work the same way (probably not), but it should help you to get started.

Sorry, it's all a bit painful, hope it'll get better :)

[littlefool]

Hello,

After studying the reference delay a bit, I found that in principle, even if the delay exists initially, it can be adaptively eliminated. Therefore, reference delay may not be the reason for the poor AEC performance. Then I compared the AEC effects of the L71 dev board and my dev board, and found that the volume of the proc0 or mic0 output channels on the L71 dev board is always lower than those on my dev board. Thus, I suspect that the high volume(gain) on my dev board may be causing the poor AEC performance. So I tried to reduce the AGC_PROFILE_ASR.max_gain on my dev board and reran the AEC test. The results showed a noticeable improvement in AEC performance. So I would like to ask if what I did is reasonable.

Here are the recording results after I adjusted the AGC_PROFILE_ASR.max_gain:


Thanks,
JY

[upav]

After studying the reference delay a bit, I found that in principle, even if the delay exists initially, it can be adaptively eliminated. Therefore, reference delay may not be the reason for the poor AEC performance.

Depends on the pipeline config you are using:
adec (automatic delay estimator and corrector (I think)) which adapts the delay as the application runs (by default will run a delay estimation once at the start)
adec_alt_arch is the same in terms of delays, different AEC + IC behaviour
fixed_delay does what it says

So if you are using any of the adec configs, it will do a delay estimation once and will fix it for the rest of the run. However, if you have a system with a fixed microphone + speaker position, I would recommend using the fixed_delay config (unless you want alt_arch).

Then I compared the AEC effects of the L71 dev board and my dev board, and found that the volume of the proc0 or mic0 output channels on the L71 dev board is always lower than those on my dev board. Thus, I suspect that the high volume(gain) on my dev board may be causing the poor AEC performance.

The input level should not affect the AEC a lot as the math inside is done using a block-floating point format. Unless your signal is clipped or too low, AEC should be ok

So I tried to reduce the AGC_PROFILE_ASR.max_gain on my dev board and reran the AEC test. The results showed a noticeable improvement in AEC performance. So I would like to ask if what I did is reasonable.

So the voice dsp pipeline (simplified) is:

delay + AEC + (ADEC) + IC + VNR + NS + AGC

AGC (automatic gain controller) sits at the very end of the pipeline and tries to keep the output at a similar level, so if you've reduced the agc gain and your keyword score became better it's not the AEC that was the problem.
Did you signal clip with the old gain setting? That might upset the ASR (if you're using one)