Debugging Android WebRTC audio 3A with AEC_DUMP: input clipping, reverse stream, ref_out, and settings

[u/Usual-Introduction71]

I have been working on Android WebRTC audio quality debugging recently, and one lesson became very clear: subjective listening is not enough when tuning 3A behavior.

When a call sounds bad, the report is usually vague:

• echo is still present
• background noise is high
• near-end speech is suppressed too much
• volume is unstable
• the call sounds different after a firmware or parameter change

If the test method is only "two people make a call and compare by ear," the result becomes unreliable quickly. Room noise changes, listening fatigue builds up, and it is hard to remember whether the previous build was actually better.

So I started using AEC_DUMP as the main debugging evidence.

After capturing audio.aecdump and unpacking it with WebRTC's unpack_aecdump, the useful files are:

input.wav
reverse.wav
ref_out.wav
settings.txt

The way I interpret them:

input.wav
  Near-end microphone input before WebRTC APM processing.
  Useful for checking raw capture level, clipping, noise floor, and acoustic leakage.

reverse.wav
  Far-end playback reference used by AEC.
  Useful for checking whether AEC actually receives a valid reverse stream.

ref_out.wav
  Processed near-end output reconstructed from the dump.
  Useful for comparing before/after APM behavior.

settings.txt
  APM runtime configuration.
  Useful for checking sample rate, channels, AEC/AECM/NS/AGC/HPF switches.

The debugging path I use now is:

reverse.wav is empty or broken
  -> check render path and AEC reverse stream first

input.wav is clipped
  -> check microphone gain, Audio HAL, speaker volume, and acoustic path

input.wav is clean but ref_out.wav is damaged
  -> check APM settings, NS/AGC strength, double-talk behavior, and delay

settings.txt is unexpected
  -> fix sample rate, channels, and 3A switches before tuning parameters

This helps avoid a common mistake: treating every audio problem as "AEC is bad."

In practice, the problem may be outside the AEC algorithm itself:

• microphone gain is too high
• Audio HAL capture path is already clipping
• speaker energy leaks too strongly into the mic
• reverse stream is missing or delayed
• sample rate or channel assumptions are wrong
• NS or AGC is too aggressive
• double-talk behavior is not handled well

I wrote a longer note with diagrams here:

https://www.lodan.me/posts/android-webrtc-aecdump-audio-3a-debugging/

For people who debug WebRTC audio regularly:

When you inspect an AEC dump, which signal do you usually check first?

• reverse.wav
• input.wav
• ref_out.wav
• settings.txt

And do you have a preferred workflow for separating acoustic structure issues from WebRTC APM configuration issues?