AGC2 as a new APM sub-module operating with hard-coded gain.

webrtc/modules/audio_processing/agc2/agc2.h

Index: webrtc/modules/audio_processing/agc2/agc2.h
diff --git a/webrtc/modules/audio_processing/agc2/agc2.h b/webrtc/modules/audio_processing/agc2/agc2.h
new file mode 100644
index 0000000000000000000000000000000000000000..6a16bbce6315a586b33557728909cca3b8203fb0
--- /dev/null
+++ b/webrtc/modules/audio_processing/agc2/agc2.h
@@ -0,0 +1,23 @@
+/*
+ *  Copyright (c) 2017 The WebRTC project authors. All Rights Reserved.
+ *
+ *  Use of this source code is governed by a BSD-style license
+ *  that can be found in the LICENSE file in the root of the source
+ *  tree. An additional intellectual property rights grant can be found
+ *  in the file PATENTS.  All contributing project authors may
+ *  be found in the AUTHORS file in the root of the source tree.
+ */
+
+#ifndef WEBRTC_MODULES_AUDIO_PROCESSING_AGC2_AGC2_H_
+#define WEBRTC_MODULES_AUDIO_PROCESSING_AGC2_AGC2_H_
+
+namespace webrtc {
+
+class Agc2 {

[aleloi, 2017/05/02 10:11:53]

I think we should strive towards more descriptive names when we write 'real' CLs
for review.

[peah-webrtc, 2017/05/02 11:01:08]

Agree, what about GainController2 ?

[AleBzk, 2017/05/02 11:31:54]

Any suggestion?

I personally favor expanded names, so in this case I would have preferred
AdaptiveGainControl.
In this CL, I took the recent work on AEC as a reference. WDYT?

[peah-webrtc, 2017/05/02 11:45:20]

In AEC3, the folder is called AEC3, but the main class is called EchoCanceller3.

Regarding the name AdaptiveGainControl it is good. But I'd personally prefer
GainControl as
1) It is in my opinion more correct as it includes the fixed gain which is not
adaptive.
2) It is shorter.

WDYT?

[AleBzk, 2017/05/02 15:42:51]

Let's stick to AEC3 way, I used GainControl2.

+ public:
+  virtual ~Agc2() = default;

[aleloi, 2017/05/02 10:11:53]

I remember a recent virtual/not virtual discussion with @peah. I think having an
empty virtual interface doesn't add much and could cost processing time.

[peah-webrtc, 2017/05/02 11:01:08]

+1 on that. I don't think we should make this an interface if we don't
absolutely need to.

[AleBzk, 2017/05/02 11:31:54]

Having an interface allows mocking. Which otherwise becomes a pain.
WDYT for this case?

[AleBzk, 2017/05/02 11:31:54]

Well, I think it's safer to declare the dtor as virtual (see item 7 in Effective
C++).
I'll be happy to discuss this point offline.

[peah-webrtc, 2017/05/02 11:45:20]

I'm not that good at this, but if this class is not final, then I think you are
right. But if we avoid making this an interface, I don't think the virtual part
is needed.

[peah-webrtc, 2017/05/02 11:45:20]

It makes sense to include a mock if it is needed. But from the work on AEC3,
where mocks were added for the first layers, my feeling is that the value of a
mock is very limited at this level. It would basically only verify the
integration of the AGC2 in APM, and I'd personally then rather use a functional
test for that.

Let's dicuss this further offline.

I'd prefer to add a mock once it 

[AleBzk, 2017/05/02 15:42:51]

From your comments, I understand that for the time being there's no need of any
mock.
So, I removed the interface and the mock.

+};
+
+}  // namespace webrtc
+
+#endif  // WEBRTC_MODULES_AUDIO_PROCESSING_AGC2_AGC2_H_