Added basic framework for AEC3 in the audio processing module

This CL adds the basic framework for AEC3 in the audio processing module.
It will be followed by a number of other CLs that extends this framework.

BUG=webrtc:6018
Committed: https://crrev.com/e0eae3cec6f986ed756e644c596d897ce79646d8
Cr-Commit-Position: refs/heads/master@{#15593}

[peah-webrtc, 2016-12-09 10:04:55]

Description was changed from

==========
Added framework for AEC3


Added framework for AEC3

BUG=
==========

to

==========
This CL adds the basic framework for AEC3 in the audio processing module.
It will be followed by a number of other CLs that extends this framework.

BUG=webrtc:6018
==========

[peah-webrtc, 2016-12-09 10:05:15]

peah@webrtc.org changed reviewers:
+ aleloi@webrtc.org, henrik.lundin@webrtc.org, ivoc@webrtc.org

[peah-webrtc, 2016-12-09 10:05:16]

PTAL
Thanks!

[aleloi, 2016-12-09 13:30:04]

LG on everything but but audio_processing_impl.*, which I haven't managed to get
through yet.

https://codereview.webrtc.org/2567513003/diff/1/webrtc/modules/audio_processi...
File webrtc/modules/audio_processing/echo_cancellation_impl.cc (left):

https://codereview.webrtc.org/2567513003/diff/1/webrtc/modules/audio_processi...
webrtc/modules/audio_processing/echo_cancellation_impl.cc:497: aec3_enabled_ ? 1
: 0);
The member aec3_enabled_ is not used any longer, so there is no need for it.

https://codereview.webrtc.org/2567513003/diff/1/webrtc/modules/audio_processi...
File webrtc/modules/audio_processing/echo_cancellation_impl.cc (right):

https://codereview.webrtc.org/2567513003/diff/1/webrtc/modules/audio_processi...
webrtc/modules/audio_processing/echo_cancellation_impl.cc:346: std::string
description = "";
Maybe change body to ternary operator one-liner?

https://codereview.webrtc.org/2567513003/diff/1/webrtc/modules/audio_processi...
File webrtc/modules/audio_processing/include/audio_processing.h (right):

https://codereview.webrtc.org/2567513003/diff/1/webrtc/modules/audio_processi...
webrtc/modules/audio_processing/include/audio_processing.h:270: };
Should webrtc::ConfigOptionID::kEchoCanceller3 be deprecated now that AEC3
enabling is done with this struct?

[aleloi, 2016-12-09 14:11:06]

A few small comments on audio_processing_impl.

https://codereview.webrtc.org/2567513003/diff/1/webrtc/modules/audio_processi...
File webrtc/modules/audio_processing/audio_processing_impl.cc (right):

https://codereview.webrtc.org/2567513003/diff/1/webrtc/modules/audio_processi...
webrtc/modules/audio_processing/audio_processing_impl.cc:442: const int
capture_audiobuffer_num_channels =
I suggest updating this variable based on the presence of aec3 instead of the
new if branch below. Otherwise the logic is harder to follow: "if aec3 enabled,
set the number of capture AudioBuffer channels to 1, otherwise to
capture_audiobuffer_num_channels"

https://codereview.webrtc.org/2567513003/diff/1/webrtc/modules/audio_processi...
webrtc/modules/audio_processing/audio_processing_impl.cc:657:
AudioProcessing::Config::EchoCanceller3 default_config;
Should default_config be assigned to config_.echo_canceller3 here?

https://codereview.webrtc.org/2567513003/diff/1/webrtc/modules/audio_processi...
webrtc/modules/audio_processing/audio_processing_impl.cc:1172:
(!private_submodules_->echo_canceller3)) {
Superfluous parentheses.

[ivoc, 2016-12-09 14:11:10]

https://codereview.webrtc.org/2567513003/diff/1/webrtc/modules/audio_processi...
File webrtc/modules/audio_processing/aec3/echo_canceller3.cc (right):

https://codereview.webrtc.org/2567513003/diff/1/webrtc/modules/audio_processi...
webrtc/modules/audio_processing/aec3/echo_canceller3.cc:24: ++instance_count_;
Not sure if this is a concern in practice, but this is a potential race
condition if EchoCanceller3 is constructed on multiple threads.

https://codereview.webrtc.org/2567513003/diff/1/webrtc/modules/audio_processi...
File webrtc/modules/audio_processing/aec3/echo_canceller3.h (right):

https://codereview.webrtc.org/2567513003/diff/1/webrtc/modules/audio_processi...
webrtc/modules/audio_processing/aec3/echo_canceller3.h:26: void
AnalyzeCapture(AudioBuffer* capture);
Why does AEC3 have both AnalyzeCapture and ProcessCapture? Isn't ProcessCapture
enough?

https://codereview.webrtc.org/2567513003/diff/1/webrtc/modules/audio_processi...
File webrtc/modules/audio_processing/audio_processing_impl.cc (right):

https://codereview.webrtc.org/2567513003/diff/1/webrtc/modules/audio_processi...
webrtc/modules/audio_processing/audio_processing_impl.cc:1172:
(!private_submodules_->echo_canceller3)) {
The braces are not needed here, it's okay to use "if (a && !b)"

[peah-webrtc, 2016-12-12 19:46:08]

Patchset #2 (id:20001) has been deleted

[peah-webrtc, 2016-12-12 19:46:46]

Thanks for the reviews!

Here are some updates in response to the comments.

https://codereview.webrtc.org/2567513003/diff/1/webrtc/modules/audio_processi...
File webrtc/modules/audio_processing/aec3/echo_canceller3.cc (right):

https://codereview.webrtc.org/2567513003/diff/1/webrtc/modules/audio_processi...
webrtc/modules/audio_processing/aec3/echo_canceller3.cc:24: ++instance_count_;
On 2016/12/09 14:11:09, ivoc wrote:
> Not sure if this is a concern in practice, but this is a potential race
> condition if EchoCanceller3 is constructed on multiple threads.

Great point! It is only used in offline simulation though, so it should be fine.
But the increment may be causing an issue. Furthermore, there should only be one
instance active at the same time of the AEC.

WDYT? Is it ok to keep it like this?

https://codereview.webrtc.org/2567513003/diff/1/webrtc/modules/audio_processi...
File webrtc/modules/audio_processing/aec3/echo_canceller3.h (right):

https://codereview.webrtc.org/2567513003/diff/1/webrtc/modules/audio_processi...
webrtc/modules/audio_processing/aec3/echo_canceller3.h:26: void
AnalyzeCapture(AudioBuffer* capture);
On 2016/12/09 14:11:09, ivoc wrote:
> Why does AEC3 have both AnalyzeCapture and ProcessCapture? Isn't
ProcessCapture
> enough?

Both are needed as the capture signal needs to be analyzed before the
band-splitting (in order to properly detect signal saturation) and processed
after the band-splitting.

https://codereview.webrtc.org/2567513003/diff/1/webrtc/modules/audio_processi...
File webrtc/modules/audio_processing/audio_processing_impl.cc (right):

https://codereview.webrtc.org/2567513003/diff/1/webrtc/modules/audio_processi...
webrtc/modules/audio_processing/audio_processing_impl.cc:442: const int
capture_audiobuffer_num_channels =
On 2016/12/09 14:11:05, aleloi wrote:
> I suggest updating this variable based on the presence of aec3 instead of the
> new if branch below. Otherwise the logic is harder to follow: "if aec3
enabled,
> set the number of capture AudioBuffer channels to 1, otherwise to
> capture_audiobuffer_num_channels"

That sounds much better!
Done.

https://codereview.webrtc.org/2567513003/diff/1/webrtc/modules/audio_processi...
webrtc/modules/audio_processing/audio_processing_impl.cc:657:
AudioProcessing::Config::EchoCanceller3 default_config;
On 2016/12/09 14:11:06, aleloi wrote:
> Should default_config be assigned to config_.echo_canceller3 here?

Thanks! Good find! This made me find some other errors as well that I corrected
in the code above.

Done.

https://codereview.webrtc.org/2567513003/diff/1/webrtc/modules/audio_processi...
webrtc/modules/audio_processing/audio_processing_impl.cc:1172:
(!private_submodules_->echo_canceller3)) {
On 2016/12/09 14:11:06, aleloi wrote:
> Superfluous parentheses.

Done.

https://codereview.webrtc.org/2567513003/diff/1/webrtc/modules/audio_processi...
webrtc/modules/audio_processing/audio_processing_impl.cc:1172:
(!private_submodules_->echo_canceller3)) {
On 2016/12/09 14:11:09, ivoc wrote:
> The braces are not needed here, it's okay to use "if (a && !b)"

Done.

https://codereview.webrtc.org/2567513003/diff/1/webrtc/modules/audio_processi...
File webrtc/modules/audio_processing/echo_cancellation_impl.cc (left):

https://codereview.webrtc.org/2567513003/diff/1/webrtc/modules/audio_processi...
webrtc/modules/audio_processing/echo_cancellation_impl.cc:497: aec3_enabled_ ? 1
: 0);
On 2016/12/09 13:30:04, aleloi wrote:
> The member aec3_enabled_ is not used any longer, so there is no need for it.

Done.

https://codereview.webrtc.org/2567513003/diff/1/webrtc/modules/audio_processi...
File webrtc/modules/audio_processing/echo_cancellation_impl.cc (right):

https://codereview.webrtc.org/2567513003/diff/1/webrtc/modules/audio_processi...
webrtc/modules/audio_processing/echo_cancellation_impl.cc:346: std::string
description = "";
On 2016/12/09 13:30:04, aleloi wrote:
> Maybe change body to ternary operator one-liner?

Good point!
Done.

https://codereview.webrtc.org/2567513003/diff/1/webrtc/modules/audio_processi...
File webrtc/modules/audio_processing/include/audio_processing.h (right):

https://codereview.webrtc.org/2567513003/diff/1/webrtc/modules/audio_processi...
webrtc/modules/audio_processing/include/audio_processing.h:270: };
On 2016/12/09 13:30:04, aleloi wrote:
> Should webrtc::ConfigOptionID::kEchoCanceller3 be deprecated now that AEC3
> enabling is done with this struct?

Good point! I added that as well.
Done.

[aleloi, 2016-12-12 19:58:53]

I can't spot anything more, lgtm!

[hlundin-webrtc, 2016-12-12 21:35:21]

Nice! A few comments.

https://codereview.webrtc.org/2567513003/diff/40001/webrtc/modules/audio_proc...
File webrtc/modules/audio_processing/aec/aec_core.h (right):

https://codereview.webrtc.org/2567513003/diff/40001/webrtc/modules/audio_proc...
webrtc/modules/audio_processing/aec/aec_core.h:242: // 1 = next generation aec
mode enabled, 0 = disabled.
This comment feels abandoned.

https://codereview.webrtc.org/2567513003/diff/40001/webrtc/modules/audio_proc...
File webrtc/modules/audio_processing/aec3/echo_canceller3.cc (right):

https://codereview.webrtc.org/2567513003/diff/40001/webrtc/modules/audio_proc...
webrtc/modules/audio_processing/aec3/echo_canceller3.cc:16: int
EchoCanceller3::instance_count_ = 0;
Is this thread-safe? See
https://sites.google.com/a/chromium.org/dev/developers/coding-style/cpp-dos-a....

https://codereview.webrtc.org/2567513003/diff/40001/webrtc/modules/audio_proc...
webrtc/modules/audio_processing/aec3/echo_canceller3.cc:29: bool
EchoCanceller3::AnalyzeRender(AudioBuffer* render) const {
It's hard to tell from this dummy implementation, but does the parameter have to
be non-const?

https://codereview.webrtc.org/2567513003/diff/40001/webrtc/modules/audio_proc...
webrtc/modules/audio_processing/aec3/echo_canceller3.cc:35: void
EchoCanceller3::AnalyzeCapture(AudioBuffer* capture) {}
Same here: Can you make the input const? The name of the method suggests that it
will just "look" at the data.

https://codereview.webrtc.org/2567513003/diff/40001/webrtc/modules/audio_proc...
File webrtc/modules/audio_processing/aec3/echo_canceller3.h (right):

https://codereview.webrtc.org/2567513003/diff/40001/webrtc/modules/audio_proc...
webrtc/modules/audio_processing/aec3/echo_canceller3.h:25: bool
AnalyzeRender(AudioBuffer* farend) const;
Method comments would be appreciated.

https://codereview.webrtc.org/2567513003/diff/40001/webrtc/modules/audio_proc...
File webrtc/modules/audio_processing/audio_processing_impl.cc (right):

https://codereview.webrtc.org/2567513003/diff/40001/webrtc/modules/audio_proc...
webrtc/modules/audio_processing/audio_processing_impl.cc:442: int
capture_audiobuffer_num_channels;
I would argue that you could keep the code the way it was, but add extra
conditions in the case of AEC3 enabled:
if (private_submodules_->echo_canceller3) {
  RTC_DCHECK(!capture_nonlocked_.beamformer_enabled);
  RTC_DCHECK_EQ(capture_audiobuffer_num_channels, 1);
}

https://codereview.webrtc.org/2567513003/diff/40001/webrtc/modules/audio_proc...
File webrtc/modules/audio_processing/include/audio_processing.h (left):

https://codereview.webrtc.org/2567513003/diff/40001/webrtc/modules/audio_proc...
webrtc/modules/audio_processing/include/audio_processing.h:71: // Enables the
next generation AEC functionality. This feature replaces the
Why not keep this description with the new struct?

[peah-webrtc, 2016-12-13 11:23:02]

https://codereview.webrtc.org/2567513003/diff/40001/webrtc/modules/audio_proc...
File webrtc/modules/audio_processing/aec/aec_core.h (right):

https://codereview.webrtc.org/2567513003/diff/40001/webrtc/modules/audio_proc...
webrtc/modules/audio_processing/aec/aec_core.h:242: // 1 = next generation aec
mode enabled, 0 = disabled.
On 2016/12/12 21:35:21, hlundin-webrtc wrote:
> This comment feels abandoned.

Good find! I revised the comment to match the refined filter adaptation flag.

Done.

https://codereview.webrtc.org/2567513003/diff/40001/webrtc/modules/audio_proc...
File webrtc/modules/audio_processing/aec3/echo_canceller3.cc (right):

https://codereview.webrtc.org/2567513003/diff/40001/webrtc/modules/audio_proc...
webrtc/modules/audio_processing/aec3/echo_canceller3.cc:16: int
EchoCanceller3::instance_count_ = 0;
On 2016/12/12 21:35:21, hlundin-webrtc wrote:
> Is this thread-safe? See
>
https://sites.google.com/a/chromium.org/dev/developers/coding-style/cpp-dos-a....

I added an atomic operation for this. That should do it.
PTAL

Done.

https://codereview.webrtc.org/2567513003/diff/40001/webrtc/modules/audio_proc...
webrtc/modules/audio_processing/aec3/echo_canceller3.cc:29: bool
EchoCanceller3::AnalyzeRender(AudioBuffer* render) const {
On 2016/12/12 21:35:21, hlundin-webrtc wrote:
> It's hard to tell from this dummy implementation, but does the parameter have
to
> be non-const?

In a perfect world, it shouldn't. But the AudioBuffer class works in such a way
that it does on-demand conversions between floating and fixed point samples.
This means, that even though AnalyzeRender only reads the AudioBuffer, that
reading may mutate the AudioBuffer in the sense that it may do an internal
on-demand conversion to floating point which then is cached internally inside
AudioBuffer.

https://codereview.webrtc.org/2567513003/diff/40001/webrtc/modules/audio_proc...
webrtc/modules/audio_processing/aec3/echo_canceller3.cc:35: void
EchoCanceller3::AnalyzeCapture(AudioBuffer* capture) {}
On 2016/12/12 21:35:21, hlundin-webrtc wrote:
> Same here: Can you make the input const? The name of the method suggests that
it
> will just "look" at the data.

That would make sense. But with the current AudioBuffer implementation, it is
not possible. (see above explanation).

https://codereview.webrtc.org/2567513003/diff/40001/webrtc/modules/audio_proc...
File webrtc/modules/audio_processing/aec3/echo_canceller3.h (right):

https://codereview.webrtc.org/2567513003/diff/40001/webrtc/modules/audio_proc...
webrtc/modules/audio_processing/aec3/echo_canceller3.h:25: bool
AnalyzeRender(AudioBuffer* farend) const;
On 2016/12/12 21:35:21, hlundin-webrtc wrote:
> Method comments would be appreciated.

Done.

https://codereview.webrtc.org/2567513003/diff/40001/webrtc/modules/audio_proc...
File webrtc/modules/audio_processing/audio_processing_impl.cc (right):

https://codereview.webrtc.org/2567513003/diff/40001/webrtc/modules/audio_proc...
webrtc/modules/audio_processing/audio_processing_impl.cc:442: int
capture_audiobuffer_num_channels;
On 2016/12/12 21:35:21, hlundin-webrtc wrote:
> I would argue that you could keep the code the way it was, but add extra
> conditions in the case of AEC3 enabled:
> if (private_submodules_->echo_canceller3) {
>   RTC_DCHECK(!capture_nonlocked_.beamformer_enabled);
>   RTC_DCHECK_EQ(capture_audiobuffer_num_channels, 1);
> }
>  

I'm not really sure what you mean. The advantage that I see with the new code is
that the audiobuffer_num_channels is set correctly. Before it was overridden
when AEC3 was activated.

https://codereview.webrtc.org/2567513003/diff/40001/webrtc/modules/audio_proc...
File webrtc/modules/audio_processing/include/audio_processing.h (left):

https://codereview.webrtc.org/2567513003/diff/40001/webrtc/modules/audio_proc...
webrtc/modules/audio_processing/include/audio_processing.h:71: // Enables the
next generation AEC functionality. This feature replaces the
On 2016/12/12 21:35:21, hlundin-webrtc wrote:
> Why not keep this description with the new struct?

I did that, but modified the text a bit.

PTAL

[hlundin-webrtc, 2016-12-14 08:15:56]

lgtm

https://codereview.webrtc.org/2567513003/diff/40001/webrtc/modules/audio_proc...
File webrtc/modules/audio_processing/aec3/echo_canceller3.cc (right):

https://codereview.webrtc.org/2567513003/diff/40001/webrtc/modules/audio_proc...
webrtc/modules/audio_processing/aec3/echo_canceller3.cc:29: bool
EchoCanceller3::AnalyzeRender(AudioBuffer* render) const {
On 2016/12/13 11:23:02, peah-webrtc wrote:
> On 2016/12/12 21:35:21, hlundin-webrtc wrote:
> > It's hard to tell from this dummy implementation, but does the parameter
have
> to
> > be non-const?
> 
> In a perfect world, it shouldn't. But the AudioBuffer class works in such a
way
> that it does on-demand conversions between floating and fixed point samples.
> This means, that even though AnalyzeRender only reads the AudioBuffer, that
> reading may mutate the AudioBuffer in the sense that it may do an internal
> on-demand conversion to floating point which then is cached internally inside
> AudioBuffer. 

Acknowledged.

https://codereview.webrtc.org/2567513003/diff/40001/webrtc/modules/audio_proc...
File webrtc/modules/audio_processing/audio_processing_impl.cc (right):

https://codereview.webrtc.org/2567513003/diff/40001/webrtc/modules/audio_proc...
webrtc/modules/audio_processing/audio_processing_impl.cc:442: int
capture_audiobuffer_num_channels;
On 2016/12/13 11:23:02, peah-webrtc wrote:
> On 2016/12/12 21:35:21, hlundin-webrtc wrote:
> > I would argue that you could keep the code the way it was, but add extra
> > conditions in the case of AEC3 enabled:
> > if (private_submodules_->echo_canceller3) {
> >   RTC_DCHECK(!capture_nonlocked_.beamformer_enabled);
> >   RTC_DCHECK_EQ(capture_audiobuffer_num_channels, 1);
> > }
> >  
> 
> I'm not really sure what you mean. The advantage that I see with the new code
is
> that the audiobuffer_num_channels is set correctly. Before it was overridden
> when AEC3 was activated.

So you do want the silent over-ride of num channels for AEC3? In that case, this
is fine.

[peah-webrtc, 2016-12-14 08:52:19]

https://codereview.webrtc.org/2567513003/diff/40001/webrtc/modules/audio_proc...
File webrtc/modules/audio_processing/audio_processing_impl.cc (right):

https://codereview.webrtc.org/2567513003/diff/40001/webrtc/modules/audio_proc...
webrtc/modules/audio_processing/audio_processing_impl.cc:442: int
capture_audiobuffer_num_channels;
On 2016/12/14 08:15:56, hlundin-webrtc wrote:
> On 2016/12/13 11:23:02, peah-webrtc wrote:
> > On 2016/12/12 21:35:21, hlundin-webrtc wrote:
> > > I would argue that you could keep the code the way it was, but add extra
> > > conditions in the case of AEC3 enabled:
> > > if (private_submodules_->echo_canceller3) {
> > >   RTC_DCHECK(!capture_nonlocked_.beamformer_enabled);
> > >   RTC_DCHECK_EQ(capture_audiobuffer_num_channels, 1);
> > > }
> > >  
> > 
> > I'm not really sure what you mean. The advantage that I see with the new
code
> is
> > that the audiobuffer_num_channels is set correctly. Before it was overridden
> > when AEC3 was activated.
> 
> So you do want the silent over-ride of num channels for AEC3? In that case,
this
> is fine.

No, that is not how it works. This forces down-mixing to mono internally in the
processing chain. The output is then upmixed if it is set to stereo. 

As it is currently (without AEC3) we do:
1) If the beamformer is active, after the signal beamformer analysis the signal
is forced to be downmixed to mono.
2) If the beamformer is not active, the processing is done on the number of
output, meaning that if there are more than 1 output channel, more than one AEC
may be operating.

We should change this as well further on.

[ivoc, 2016-12-14 08:54:15]

lgtm

https://codereview.webrtc.org/2567513003/diff/1/webrtc/modules/audio_processi...
File webrtc/modules/audio_processing/aec3/echo_canceller3.cc (right):

https://codereview.webrtc.org/2567513003/diff/1/webrtc/modules/audio_processi...
webrtc/modules/audio_processing/aec3/echo_canceller3.cc:24: ++instance_count_;
On 2016/12/12 19:46:45, peah-webrtc wrote:
> On 2016/12/09 14:11:09, ivoc wrote:
> > Not sure if this is a concern in practice, but this is a potential race
> > condition if EchoCanceller3 is constructed on multiple threads.
> 
> Great point! It is only used in offline simulation though, so it should be
fine.
> But the increment may be causing an issue. Furthermore, there should only be
one
> instance active at the same time of the AEC.
> 
> WDYT? Is it ok to keep it like this?

Let's keep it like this.

https://codereview.webrtc.org/2567513003/diff/1/webrtc/modules/audio_processi...
File webrtc/modules/audio_processing/aec3/echo_canceller3.h (right):

https://codereview.webrtc.org/2567513003/diff/1/webrtc/modules/audio_processi...
webrtc/modules/audio_processing/aec3/echo_canceller3.h:26: void
AnalyzeCapture(AudioBuffer* capture);
On 2016/12/12 19:46:45, peah-webrtc wrote:
> On 2016/12/09 14:11:09, ivoc wrote:
> > Why does AEC3 have both AnalyzeCapture and ProcessCapture? Isn't
> ProcessCapture
> > enough?
> 
> Both are needed as the capture signal needs to be analyzed before the
> band-splitting (in order to properly detect signal saturation) and processed
> after the band-splitting.

Acknowledged.

[peah-webrtc, 2016-12-14 08:56:16]

https://codereview.webrtc.org/2567513003/diff/1/webrtc/modules/audio_processi...
File webrtc/modules/audio_processing/aec3/echo_canceller3.cc (right):

https://codereview.webrtc.org/2567513003/diff/1/webrtc/modules/audio_processi...
webrtc/modules/audio_processing/aec3/echo_canceller3.cc:24: ++instance_count_;
On 2016/12/14 08:54:15, ivoc wrote:
> On 2016/12/12 19:46:45, peah-webrtc wrote:
> > On 2016/12/09 14:11:09, ivoc wrote:
> > > Not sure if this is a concern in practice, but this is a potential race
> > > condition if EchoCanceller3 is constructed on multiple threads.
> > 
> > Great point! It is only used in offline simulation though, so it should be
> fine.
> > But the increment may be causing an issue. Furthermore, there should only be
> one
> > instance active at the same time of the AEC.
> > 
> > WDYT? Is it ok to keep it like this?
> 
> Let's keep it like this.

I ended up changing it to using an atomic operation. So now it should be fine.

Done.

[peah-webrtc, 2016-12-14 08:56:20]

The CQ bit was checked by peah@webrtc.org

[peah-webrtc, 2016-12-14 08:56:21]

The patchset sent to the CQ was uploaded after l-g-t-m from aleloi@webrtc.org
Link to the patchset: https://codereview.webrtc.org/2567513003/#ps60001 (title:
"Changes in response to reviewer comments")

[commit-bot: I haz the power, 2016-12-14 08:56:29]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...

[commit-bot: I haz the power, 2016-12-14 09:16:24]

CQ is committing da patch.

Bot data: {"patchset_id": 60001, "attempt_start_ts": 1481705780952840,
"parent_rev": "97986506457efd343b6b8894286c2abed95d4bac", "commit_rev":
"a212510cc969e8905c08ec5ce1b1262e9cf442e8"}

[commit-bot: I haz the power, 2016-12-14 09:16:26]

Description was changed from

==========
This CL adds the basic framework for AEC3 in the audio processing module.
It will be followed by a number of other CLs that extends this framework.

BUG=webrtc:6018
==========

to

==========
This CL adds the basic framework for AEC3 in the audio processing module.
It will be followed by a number of other CLs that extends this framework.

BUG=webrtc:6018

Review-Url: https://codereview.webrtc.org/2567513003
==========

[commit-bot: I haz the power, 2016-12-14 09:16:27]

Committed patchset #3 (id:60001)

[commit-bot: I haz the power, 2016-12-14 09:16:36]

Description was changed from

==========
This CL adds the basic framework for AEC3 in the audio processing module.
It will be followed by a number of other CLs that extends this framework.

BUG=webrtc:6018

Review-Url: https://codereview.webrtc.org/2567513003
==========

to

==========
This CL adds the basic framework for AEC3 in the audio processing module.
It will be followed by a number of other CLs that extends this framework.

BUG=webrtc:6018

Committed: https://crrev.com/e0eae3cec6f986ed756e644c596d897ce79646d8
Cr-Commit-Position: refs/heads/master@{#15593}
==========

[commit-bot: I haz the power, 2016-12-14 09:16:37]

Patchset 3 (id:??) landed as
https://crrev.com/e0eae3cec6f986ed756e644c596d897ce79646d8
Cr-Commit-Position: refs/heads/master@{#15593}