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

webrtc/modules/audio_processing/agc2/gain_controller2.h

+/*
+ *  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_GAIN_CONTROLLER2_H_
+#define WEBRTC_MODULES_AUDIO_PROCESSING_AGC2_GAIN_CONTROLLER2_H_
+
+#include <memory>
+#include <string>
+
+#include "webrtc/base/constructormagic.h"
+#include "webrtc/modules/audio_processing/include/audio_processing.h"
+#include "webrtc/modules/audio_processing/agc2/digital_gain_applier.h"
+
+namespace webrtc {
+
+class ApmDataDumper;
+class AudioBuffer;
+
+// Gain Controller 2 aims to automatically adjusting levels by acting on the

[aleloi, 2017/05/18 15:01:17]

adjusting -> adjust

[AleBzk, 2017/05/19 13:15:41]

Done.

+// microphone gain and/or applying digital gain.
+//
+// It temporarily implements a hard-coded gain mode only.
+class GainController2 {
+ public:
+  explicit GainController2(int sample_rate_hz);
+  ~GainController2();
+
+  void Process(AudioBuffer* audio);

[aleloi, 2017/05/18 15:01:17]

Do we want the GainController to depend on 'AudioBuffer'? It'll make it
difficult to make it a separate GN target. AudioBuffer is a big interface in
which lots of parts are not needed for this class. It also makes it less clear
that this component operates outside the band-split domain.


Can we change the AudioBuffer to a struct wrapping a 'float**', num_channels,
num_samples? See FloatAudioFrame in audio_processing/include/aec_dump.h of this
not-yet-landed CL: https://codereview.webrtc.org/2778783002/ 

[peah-webrtc, 2017/05/18 20:17:52]

I also think that we should limit the AudioBuffer usage. Is there some way that
we easily can avoid it being part of GainController2, without adding a lot of
boilerplate code to audio_processing_impl.cc?

[AleBzk, 2017/05/19 13:15:41]

I used AudioBuffer for the first time recently and noticed that it is full of
responsibilities (which I personally don't like).
So, I was happy to hear that its usage will be deprecated at some point.

However, I am not sure if we want our own "workaround" or, as Per said,
boilerplate code in APM (when GainController2::Process() is called). Let's land
this CL first and then make another one in which we remove the dependency on
AudioBuffer - let's discuss which way to go offline.

[peah-webrtc, 2017/05/22 08:16:00]

That sounds good I think. Replacing AudioBuffer is a huge thing, and I'd rather
for now settle for refraining from using it inside the submodules.

+
+  static bool Validate(const AudioProcessing::Config::GainController2& config);
+  static std::string ToString(
+      const AudioProcessing::Config::GainController2& config);
+
+ private:
+  int sample_rate_hz_;
+  std::unique_ptr<ApmDataDumper> data_dumper_;
+  DigitalGainApplier digital_gain_applier_;
+  static int instance_count_;
+  // TODO(alessiob): Remove once a meaningful gain controller mode is
+  // implemented.
+  const float gain_;
+  RTC_DISALLOW_COPY_AND_ASSIGN(GainController2);
+};
+
+}  // namespace webrtc
+
+#endif  // WEBRTC_MODULES_AUDIO_PROCESSING_AGC2_GAIN_CONTROLLER2_H_