Was it AppRTC call or some other application? What Chrome version was that? Where there other tabs open during the call?

We would also need trace recording to be able to analyze what was going on in audio stack. Is it possible to reproduce it and record traces with the following categories:
audio, webaudio, video, gpu, blink_gc?

Also, is it possible that AEC dump recording itself affects the delay? Is it done off real-time thread now?

Thanks!

What audio device was used?

The audio device used was the built-in loudspeakers and microphone on the MacBook air unit. Ambient noise suppression (in the hw) was turned on.

Re #1:
This was a call in Chrome using Hangouts. The Chrome version was Canary M66 (build was updated to latest Canary build available on Thursday morning, Feb 15, 2018).

I think there were at least 3 other tabs open during the call. I had at least 
-chrome://webrtc-internals
-chrome://flags
-https://calendar.google.com/calendar/r
open beyond the tab with the hangouts call.

The tab with the hangouts call was the active tab throughout the call and no one was using the machine during the call.

I have no idea whether the aecdump recording can affect the delay. The recording does not add any delay but it could perhaps trigger the delay to be increased? In that case, that delay is added in audio buffers outside of the audio processing module.

As far as I know, the actual storing of the aecdump is nowdays done in another thread using a task queue.

It should be noted, however, that the recording started only after the issue with full echo leakage occurred which indicates (but not proves) that the delay increase occurred independently of the aecdump recording.

Regarding a trace, is it possible to create Chrome traces that are longer than about 10 seconds? It is hard to catch this kind of an event during a call while at the same time covering it with a Chrome trace when the traces are so short.

"Record continuously" mode is recording - well, continuously, constantly overriding the buffer. From my experience it captures ~10 last seconds.
So could you turn on tracing in this mode, and stop as soon as you hear a problem? Thanks!

peah@ could you suggest: What delay values are tolerable for AEC? And could it help to use audio buffer timestamps directly?

For AEC, the answer is that any delay works, but an upper bound is needed as the AEC needs to take headroom for that.

However, it is very important to reduce the round-trip delay as that has a direct impact on the end-user experience. From that perspective I would say that audio buffer delays of 390ms are much too long.

I cannot give a good value for what a tolerable delay for a call would be. My view is that we should minimize the delay as much as possible without compromising a stable pipeline.
For instance, if 100 ms delay would cause 10 glitches per minute then for sure a higher delay is better. But if a 100 ms delay cause one glitch per hour, then that would for sure be an acceptable 
 

To summarize: the AEC impact of the delay is not the primary issue. The main issue is instead that it increases the round-trip delay which decreases the end-user experience.