Add an extended filter mode to AEC.

This mode extends the filter length from the current 48 ms to 128 ms.
It is runtime selectable which allows it to be enabled through
experiment. We reuse the DelayCorrection infrastructure to avoid having
to replumb everything up to libjingle.

Increases AEC complexity by ~50% on modern x86 CPUs.
Measurements (in percent of usage on one core):

Machine/CPU                                     Normal Extended
MacBook Retina (Early 2013),
Core i7 Ivy Bridge (2.7 GHz, hyperthreaded)     0.6%   0.9%

MacBook Air (Late 2010), Core 2 Duo (2.13 GHz)  1.4%   2.7%

Chromebook Pixel, Core i5 Ivy Bridge (1.8 GHz)  0.6%   1.0%

Samsung ARM Chromebook,
Samsung Exynos 5 Dual (1.7 GHz)                 3.2%   5.6%

The relative value is large of course but the absolute should be
acceptable in order to have a working AEC on some platforms.

Detailed changes to the algorithm:
- The filter length is changed from 48 to 128 ms. This comes with tuning
of several parameters: i) filter adaptation stepsize and error
threshold; ii) non-linear processing smoothing and overdrive.
- Option to ignore the reported delays on platforms which we deem
sufficiently unreliable. Currently this will be enabled in Chromium for
Mac.
- Faster startup times by removing the excessive "startup phase"
processing of reported delays.
- Much more conservative adjustments to the far-end read pointer. We
smooth the delay difference more heavily, and back off from the
difference more. Adjustments force a readaptation of the filter, so they
should be avoided except when really necessary.

Corresponds to these changes:
https://chromereviews.googleplex.com/9412014
https://chromereviews.googleplex.com/9514013
https://chromereviews.googleplex.com/9960013

BUG=454,827,1261
R=bjornv@webrtc.org

Review URL: https://webrtc-codereview.appspot.com/2151007

git-svn-id: http://webrtc.googlecode.com/svn/trunk@4837 4adac7df-926f-26a2-2b94-8c16560cd09d

webrtc/modules/audio_processing/echo_cancellation_impl.h

@@ -15,6 +15,30 @@
 
 namespace webrtc {
 
+// Use to enable the delay correction feature. This now engages an extended
+// filter mode in the AEC, along with robustness measures around the reported
+// system delays. It comes with a significant increase in AEC complexity, but is
+// much more robust to unreliable reported delays.
+//
+// Detailed changes to the algorithm:
+// - The filter length is changed from 48 to 128 ms. This comes with tuning of
+//   several parameters: i) filter adaptation stepsize and error threshold;
+//   ii) non-linear processing smoothing and overdrive.
+// - Option to ignore the reported delays on platforms which we deem
+//   sufficiently unreliable. See WEBRTC_UNTRUSTED_DELAY in echo_cancellation.c.
+// - Faster startup times by removing the excessive "startup phase" processing
+//   of reported delays.
+// - Much more conservative adjustments to the far-end read pointer. We smooth
+//   the delay difference more heavily, and back off from the difference more.
+//   Adjustments force a readaptation of the filter, so they should be avoided
+//   except when really necessary.
+struct DelayCorrection {
+  DelayCorrection() : enabled(false) {}
+  DelayCorrection(bool enabled) : enabled(enabled) {}
+
+  bool enabled;
+};
+
 class AudioProcessingImpl;
 class AudioBuffer;
 
@@ -34,6 +58,7 @@ class EchoCancellationImpl : public EchoCancellationImplWrapper {
 
   // ProcessingComponent implementation.
   virtual int Initialize() OVERRIDE;
+  virtual void SetExtraOptions(const Config& config) OVERRIDE;
 
  private:
   // EchoCancellation implementation.
@@ -70,6 +95,7 @@ class EchoCancellationImpl : public EchoCancellationImplWrapper {
   bool was_stream_drift_set_;
   bool stream_has_echo_;
   bool delay_logging_enabled_;
+  bool delay_correction_enabled_;
 };
 
 }  // namespace webrtc