Corrected the behavior in AEC3 during buffer overruns and underruns

webrtc/modules/audio_processing/aec3/shadow_filter_update_gain.cc

Index: webrtc/modules/audio_processing/aec3/shadow_filter_update_gain.cc
diff --git a/webrtc/modules/audio_processing/aec3/shadow_filter_update_gain.cc b/webrtc/modules/audio_processing/aec3/shadow_filter_update_gain.cc
index 85bc11fb0d631865cc45ec2e25b019aa047b3509..61a1f575b13b5062f6304781705d63d1a2a16f69 100644
--- a/webrtc/modules/audio_processing/aec3/shadow_filter_update_gain.cc
+++ b/webrtc/modules/audio_processing/aec3/shadow_filter_update_gain.cc
@@ -17,6 +17,13 @@
 
 namespace webrtc {
 
+void ShadowFilterUpdateGain::HandleEchoPathChange() {
+  // TODO(peah): Check whether this counter should instead be initialized to a
+  // large value.
+  poor_signal_excitation_counter_ = 0;
+  call_counter_ = 0;
+}

[aleloi, 2017/05/03 11:23:39]

Is there a risk that the echo canceler doesn't perform well because small
changes in the echo path cause components to be reset? Should be perhaps track
statistics for the frequency of such resets?

[peah-webrtc, 2017/05/03 11:31:23]

I see that there is a problem with the naming here. The echo path changes
referred are echo path changes introduced by buffering issues or by
nonnegligible AGC changes, and not by small variations in the echo path.

The buffering issues are logged, but maybe not to a sufficient extent. 

Ideally, the calls to HandleEchoPathChange should be very rare, so this change
is safe, in particular as the resets of the counters only pauses the filter
adaptation for 12 blocks = 48 ms.

+
 void ShadowFilterUpdateGain::Compute(
     const RenderBuffer& render_buffer,
     const RenderSignalAnalyzer& render_signal_analyzer,