​Introduction

This guide will address troubleshooting conferencing systems that echo for the far side talker.  We will cover the most common mistakes people make when designing an Acoustic Echo Cancellation [AEC] system.  AEC removes program echo from the microphone but this only works if the audio is correctly referenced.  BSS supplies template files for BLU101, BLU102 and BLU103 devices.  These templates are setup with the audio correctly referenced and provide a good starting place for most systems.

They can be accessed under the File>Open Template menu in Audio Architect or by going to

help.harmanpro.com.

See the following articles with template files:

/using-the-blu-101-blu-hif-application-guide

​/using-the-blu-103-application-guide

For more information on how AEC works see the following video demonstration of Acoustic Echo Cancellation.

/SOUNDWEB-LONDON-Acoustic-Echo-Cancellation-(AEC)

For more information on designing with AEC see the AEC Application Guide

/acoustic-echo-cancellation-application-guide​

Troubleshooting

Step 1: Determine the Source of Echo

The first step in troubleshooting echo is to determine the source the echo.

Mute audio inputs on the device until the echo is no longer present.  Start with Microphones, if the audio echo is still present then the far side may be routed back to itself.  Mute the other sources until the echo is no longer audible at the far side.  If echo persists after muting everything on the DSP, then the audio is being fed to the far side somewhere else such as a PC, Camera or codec before the audio is even processed by the DSP.

Step 2: Determine Why the Source is Producing Echo 

Microphones

The most common sources of echo are the open microphones in the room.  Normally these will pick up audio from the far side and send it back.  The AEC algorithm listens for any audio that is referenced as undesirable and removes it from the microphones.

Verify AEC

AEC processing must be applied to each microphone before it is sent to the far side.

You can also check the processing status of each channel within the block.  ERL (Echo Return Loss) and ERLE give you an indication of how well the system is identifying echo and how much gain reduction is being applied to the echo via the linear processing in the AEC algorithm before the Non Linear Processing is applied.  If the ERLE doesn't show a negative number that could indicate that the reference is not setup correctly or that there is currently no program audio being detected for removal.

Reference Return

By far the most common mistake with AEC systems is having the correct material sent to the reference return.  The most common mistakes here are:

Missing Reference Return

Each input on the reference return is unique for its channel of AEC.  If one or more of those channels is left unwired then the AEC algorithm will not remove any echo.

Multiple DSPs

If multiple DSP's are used with a conference system it is important that the reference signal is sent to each channel.

Incorrect Reference Signals 

Matrices

At first glance this design looks like it could be correct.  But the reference is picking up the dry microphones going to the room.

 This could be corrected with a dedicated output for the reference. 

However, placing the reference on its own matrix output now presents the possibility that the audio we want to cancel is not referenced correctly because things can be turned off or mis-routed.

While using a matrix is generally fine for programming it does present anyone with access to the matrix the ability to mess things up.  A better design would be to design with intent and break the matrix up into separate mixers ensuring that only the proper sources are able to be routed to each destination.

In this case each output is broken into a separate mixer instead of one big matrix which then prevents the wrong audio from being routed to an out.  Also the reference is now tied to the room which ensures that the audio is always correctly referenced.

Echo from Other Sources

If echo is still occurring when the microphones are muted then most likely the far side may be routed back to itself. Check any mixers or matrices feeding the far-side outputs and verify none of these sources is transmitting the far-side audio.

Intermittent Echo

In some cases everything will be referenced and processed correctly but there could still be echo from time to time.  This could be a result of changes causing the AEC to recalculate and re-converge.  A few common mistakes here are: 

Misplaced processing

Anything that changes or alters the audio before the AEC block will make the AEC re-converge.  This includes automixers and dynamics processing.

In the follow example the microphones will not properly converge because automixer block is before the AEC block.

Microphone Mutes

Muting microphones signal before the AEC block alters what the AEC block is hearing as it calculates the echo from the room.  This will cause echo when microphones are muted and unmuted during a call.  A workaround for this is to use the threshold in the AEC block to freeze the AEC algorithm for that channel when a microphone is muted.  This will prevent the microphone from re-converging when it is muted and unmuted during a call.

The threshold is set based on the noise floor of the microphone so that when the microphone is unmuted it is above the threshold and below the threshold when mute.  Typically this around -60 dB.

​ 

​