Chromium Code Reviews
Help | Chromium Project | Gerrit Changes | Sign in
(20)

Issue 2834643002: audioproc_f with simulated mic analog gain

Can't Edit
Can't Publish+Mail
Start Review
Created:
3 months ago by AleBzk (OOO 4-25 July)
Modified:
3 weeks, 1 day ago
CC:
webrtc-reviews_webrtc.org, AleBzk (OOO 4-25 July), peah-webrtc(OOOtoAug12), Andrew MacDonald, aleloi, tterriberry_mozilla.com, audio-team_agora.io, hlundin-webrtc (OOOtoAug6), kwiberg-webrtc, minyue-webrtc, the sun (OOO until July 24th), aluebs-webrtc, bjornv1
Target Ref:
refs/heads/master
Project:
webrtc
Visibility:
Public.

Description

audioproc_f with simulated mic analog gain The gain suggested by AGC is optionally used in audioproc_f to simulate analog gain applied to the mic. The simulation is done by applying digital gain to the input samples. This functionality is optional and disabled by default. If an AECdump is provided and the mic gain simulation is enabled, an extra "level undo" step is performed to virtually restore the unmodified mic signal. Authors: alessiob, aleloi BUG=webrtc:7494

Patch Set 1 : set_stream_analog_level and stream_analog_level moved into parent class AudioProcessingSimulator #

Total comments: 13

Patch Set 2 : Comments from Alex addressed #

Total comments: 13

Patch Set 3 : comments addressed #

Total comments: 6

Patch Set 4 : AGC simulated gain #

Total comments: 66

Patch Set 5 : FakeRecordingDevice interface simplified, UTs fixes, logs verbosity-- #

Total comments: 52

Patch Set 6 : comments addressed #

Total comments: 47

Patch Set 7 : FakeRecordingDevice refactoring, minor comments addressed #

Total comments: 3

Patch Set 8 : FakeRecordingDevice: API simplified, UTs adapted #

Total comments: 7

Patch Set 9 : fake rec device boilerplate reduced, aec dump simulated analog gain logic moved #

Total comments: 48

Patch Set 10 : Merge + comments addressed #

Total comments: 24
Unified diffs Side-by-side diffs Delta from patch set Stats (+556 lines, -32 lines) Patch
M webrtc/modules/audio_processing/BUILD.gn View 1 2 3 4 5 6 7 8 9 5 chunks +14 lines, -0 lines 3 comments Download
M webrtc/modules/audio_processing/test/aec_dump_based_simulator.h View 1 2 3 2 chunks +3 lines, -2 lines 0 comments Download
M webrtc/modules/audio_processing/test/aec_dump_based_simulator.cc View 1 2 3 4 5 6 7 8 9 4 chunks +13 lines, -19 lines 2 comments Download
M webrtc/modules/audio_processing/test/audio_processing_simulator.h View 1 2 3 4 5 6 7 8 9 4 chunks +6 lines, -0 lines 2 comments Download
M webrtc/modules/audio_processing/test/audio_processing_simulator.cc View 1 2 3 4 5 6 7 8 9 5 chunks +44 lines, -1 line 7 comments Download
A webrtc/modules/audio_processing/test/fake_recording_device.h View 1 2 3 4 5 6 7 8 9 1 chunk +90 lines, -0 lines 1 comment Download
A webrtc/modules/audio_processing/test/fake_recording_device.cc View 1 2 3 4 5 6 7 8 9 1 chunk +142 lines, -0 lines 1 comment Download
A webrtc/modules/audio_processing/test/fake_recording_device_unittest.cc View 1 2 3 4 5 6 7 8 9 1 chunk +242 lines, -0 lines 8 comments Download
M webrtc/modules/audio_processing/test/wav_based_simulator.h View 3 2 chunks +1 line, -1 line 0 comments Download
M webrtc/modules/audio_processing/test/wav_based_simulator.cc View 1 2 3 4 5 6 7 8 9 3 chunks +1 line, -9 lines 0 comments Download
Trybot results: Sign in to try more bots
Commit queue not available (can’t edit this change).

Messages

Total messages: 52 (19 generated)
AleBzk (OOO 4-25 July)
Hi Alex, This is a first patch set with some changes (incl. missing imports notified ...
3 months ago (2017-04-21 09:43:46 UTC) #4
aleloi
What will happen if we always do the gain control level updating instead of passing ...
3 months ago (2017-04-21 11:46:43 UTC) #5
aleloi
https://codereview.webrtc.org/2834643002/diff/20001/webrtc/modules/audio_processing/test/aec_dump_based_simulator.cc File webrtc/modules/audio_processing/test/aec_dump_based_simulator.cc (right): https://codereview.webrtc.org/2834643002/diff/20001/webrtc/modules/audio_processing/test/aec_dump_based_simulator.cc#newcode164 webrtc/modules/audio_processing/test/aec_dump_based_simulator.cc:164: // If so and the analog gain simulation is ...
3 months ago (2017-04-21 11:52:29 UTC) #6
AleBzk (OOO 4-25 July)
Hi Alex, Thanks a lot for your comments. PTAL, once you don't have further comments, ...
2 months, 4 weeks ago (2017-04-24 09:40:26 UTC) #7
aleloi
lgtm
2 months, 4 weeks ago (2017-04-24 11:48:28 UTC) #8
commit-bot: I haz the power
CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/2834643002/40001
2 months, 3 weeks ago (2017-04-26 09:40:11 UTC) #10
commit-bot: I haz the power
Try jobs failed on following builders: presubmit on master.tryserver.webrtc (JOB_FAILED, http://build.chromium.org/p/tryserver.webrtc/builders/presubmit/builds/16458)
2 months, 3 weeks ago (2017-04-26 09:45:01 UTC) #12
AleBzk (OOO 4-25 July)
I added Henrik, we need approval from one of the owners.
2 months, 3 weeks ago (2017-04-26 09:47:29 UTC) #14
hlundin-webrtc (OOOtoAug6)
I'm having difficulties understanding the logic. https://codereview.webrtc.org/2834643002/diff/40001/webrtc/modules/audio_processing/test/audio_processing_simulator.cc File webrtc/modules/audio_processing/test/audio_processing_simulator.cc (right): https://codereview.webrtc.org/2834643002/diff/40001/webrtc/modules/audio_processing/test/audio_processing_simulator.cc#newcode132 webrtc/modules/audio_processing/test/audio_processing_simulator.cc:132: last_specified_microphone_level_ = settings_.simulate_mic_gain ...
2 months, 3 weeks ago (2017-04-26 12:11:37 UTC) #15
peah-webrtc(OOOtoAug12)
Some drive-by comments. https://codereview.webrtc.org/2834643002/diff/40001/webrtc/modules/audio_processing/test/aec_dump_based_simulator.cc File webrtc/modules/audio_processing/test/aec_dump_based_simulator.cc (right): https://codereview.webrtc.org/2834643002/diff/40001/webrtc/modules/audio_processing/test/aec_dump_based_simulator.cc#newcode163 webrtc/modules/audio_processing/test/aec_dump_based_simulator.cc:163: // If the AECdump does not ...
2 months, 3 weeks ago (2017-04-26 12:54:44 UTC) #17
AleBzk (OOO 4-25 July)
Thanks for all your comments. I think it's best to discuss the changes offline before ...
2 months, 3 weeks ago (2017-04-26 14:19:33 UTC) #18
AleBzk (OOO 4-25 July)
After our offline discussion, I made changes to this CL. I also took into account ...
2 months, 2 weeks ago (2017-05-02 14:53:25 UTC) #19
peah-webrtc(OOOtoAug12)
Thanks for the new draft! I added some comments. It is, however, a bit hard ...
2 months, 2 weeks ago (2017-05-02 21:27:33 UTC) #20
AleBzk (OOO 4-25 July)
Finally here, PTAL
2 months, 2 weeks ago (2017-05-04 11:32:00 UTC) #22
aleloi
LG! Some comments in the unit test, though. https://codereview.webrtc.org/2834643002/diff/40001/webrtc/modules/audio_processing/test/aec_dump_based_simulator.cc File webrtc/modules/audio_processing/test/aec_dump_based_simulator.cc (right): https://codereview.webrtc.org/2834643002/diff/40001/webrtc/modules/audio_processing/test/aec_dump_based_simulator.cc#newcode163 webrtc/modules/audio_processing/test/aec_dump_based_simulator.cc:163: // ...
2 months, 2 weeks ago (2017-05-04 12:47:14 UTC) #27
peah-webrtc(OOOtoAug12)
Hi, Thanks for the new patch! I have added some comments. https://codereview.webrtc.org/2834643002/diff/100001/webrtc/modules/audio_processing/test/aec_dump_based_simulator.cc File webrtc/modules/audio_processing/test/aec_dump_based_simulator.cc (right): ...
2 months, 2 weeks ago (2017-05-05 06:28:41 UTC) #30
AleBzk (OOO 4-25 July)
Thanks a lot for your comments. I addressed everything and also added the initial mic ...
2 months, 2 weeks ago (2017-05-05 12:20:19 UTC) #31
peah-webrtc(OOOtoAug12)
Hi, Thanks for the new patch. I have some more comments. https://codereview.webrtc.org/2834643002/diff/100001/webrtc/modules/audio_processing/test/audio_processing_simulator.cc File webrtc/modules/audio_processing/test/audio_processing_simulator.cc (right): ...
2 months, 2 weeks ago (2017-05-05 20:25:22 UTC) #32
aleloi
Small quick comment response re build files and GN. More will come later. https://codereview.webrtc.org/2834643002/diff/120001/webrtc/modules/audio_processing/BUILD.gn File ...
2 months, 2 weeks ago (2017-05-08 09:46:49 UTC) #33
aleloi
https://codereview.webrtc.org/2834643002/diff/120001/webrtc/modules/audio_processing/BUILD.gn File webrtc/modules/audio_processing/BUILD.gn (right): https://codereview.webrtc.org/2834643002/diff/120001/webrtc/modules/audio_processing/BUILD.gn#newcode675 webrtc/modules/audio_processing/BUILD.gn:675: rtc_source_set("fake_recording_device") { Additional arguments for modular targets: * GN ...
2 months, 2 weeks ago (2017-05-08 10:15:24 UTC) #34
peah-webrtc(OOOtoAug12)
https://codereview.webrtc.org/2834643002/diff/120001/webrtc/modules/audio_processing/BUILD.gn File webrtc/modules/audio_processing/BUILD.gn (right): https://codereview.webrtc.org/2834643002/diff/120001/webrtc/modules/audio_processing/BUILD.gn#newcode675 webrtc/modules/audio_processing/BUILD.gn:675: rtc_source_set("fake_recording_device") { On 2017/05/08 09:46:49, aleloi wrote: > On ...
2 months, 2 weeks ago (2017-05-08 11:41:33 UTC) #35
aleloi
https://codereview.webrtc.org/2834643002/diff/120001/webrtc/modules/audio_processing/BUILD.gn File webrtc/modules/audio_processing/BUILD.gn (right): https://codereview.webrtc.org/2834643002/diff/120001/webrtc/modules/audio_processing/BUILD.gn#newcode675 webrtc/modules/audio_processing/BUILD.gn:675: rtc_source_set("fake_recording_device") { On 2017/05/08 11:41:33, peah-webrtc wrote: > On ...
2 months, 2 weeks ago (2017-05-08 12:40:50 UTC) #36
peah-webrtc(OOOtoAug12)
https://codereview.webrtc.org/2834643002/diff/120001/webrtc/modules/audio_processing/BUILD.gn File webrtc/modules/audio_processing/BUILD.gn (right): https://codereview.webrtc.org/2834643002/diff/120001/webrtc/modules/audio_processing/BUILD.gn#newcode675 webrtc/modules/audio_processing/BUILD.gn:675: rtc_source_set("fake_recording_device") { On 2017/05/08 12:40:49, aleloi wrote: > On ...
2 months, 2 weeks ago (2017-05-08 13:06:37 UTC) #37
AleBzk (OOO 4-25 July)
Hi, Sorry for the delay and thanks a lot for your comments. PTAL. Alessio https://codereview.webrtc.org/2834643002/diff/120001/webrtc/modules/audio_processing/BUILD.gn ...
2 months ago (2017-05-16 08:53:04 UTC) #38
peah-webrtc(OOOtoAug12)
Hi, Thanks for the new patch! I have added some comments. PTAL https://codereview.webrtc.org/2834643002/diff/120001/webrtc/modules/audio_processing/BUILD.gn File webrtc/modules/audio_processing/BUILD.gn ...
2 months ago (2017-05-16 12:19:36 UTC) #39
AleBzk (OOO 4-25 July)
Thank a lot for the comments! I think there is a point we should discuss ...
2 months ago (2017-05-17 11:52:24 UTC) #41
peah-webrtc(OOOtoAug12)
Hi, Thanks for the new patch! I have some more comments. PTAL https://codereview.webrtc.org/2834643002/diff/140001/webrtc/modules/audio_processing/BUILD.gn File webrtc/modules/audio_processing/BUILD.gn ...
2 months ago (2017-05-17 14:52:13 UTC) #42
AleBzk (OOO 4-25 July)
Hi again, PTAL. I didn't directly reply to the past comments to avoid the risk ...
1 month, 4 weeks ago (2017-05-23 13:56:41 UTC) #43
peah-webrtc(OOOtoAug12)
https://codereview.webrtc.org/2834643002/diff/200001/webrtc/modules/audio_processing/test/aec_dump_based_simulator.cc File webrtc/modules/audio_processing/test/aec_dump_based_simulator.cc (right): https://codereview.webrtc.org/2834643002/diff/200001/webrtc/modules/audio_processing/test/aec_dump_based_simulator.cc#newcode180 webrtc/modules/audio_processing/test/aec_dump_based_simulator.cc:180: fake_recording_device_->set_mic_level(msg.level()); On 2017/05/23 13:56:41, AleBzk wrote: > @Per: you ...
1 month, 4 weeks ago (2017-05-23 22:13:20 UTC) #44
AleBzk (OOO 4-25 July)
Hi, Sorry for the belated answer to your comments. Following Per's feedback, we now have ...
4 weeks, 1 day ago (2017-06-22 10:16:01 UTC) #46
peah-webrtc(OOOtoAug12)
Hi, Thanks for the new patch! I have added some further comments. https://codereview.webrtc.org/2834643002/diff/220001/webrtc/modules/audio_processing/test/aec_dump_based_simulator.cc File webrtc/modules/audio_processing/test/aec_dump_based_simulator.cc ...
3 weeks, 1 day ago (2017-06-29 05:45:27 UTC) #47
AleBzk (OOO 4-25 July)
Thanks Per! Getting there :) Sorry, I had an issue while merging for which I ...
3 weeks, 1 day ago (2017-06-29 11:43:37 UTC) #51
peah-webrtc(OOOtoAug12)
3 weeks, 1 day ago (2017-06-29 22:04:00 UTC) #52
Hi,
Thanks for the new patch! I have some more comments!

https://codereview.webrtc.org/2834643002/diff/220001/webrtc/modules/audio_pro...
File webrtc/modules/audio_processing/test/audio_processing_simulator.cc (right):

https://codereview.webrtc.org/2834643002/diff/220001/webrtc/modules/audio_pro...
webrtc/modules/audio_processing/test/audio_processing_simulator.cc:138:
fake_recording_device_->SimulateAnalogGain(&fwd_frame_);
On 2017/06/29 11:43:35, AleBzk wrote:
> On 2017/06/29 05:45:26, peah-webrtc wrote:
> > Why not just add the optional aec_dump_mic_level_ as an input to
> > SimulateAnalogGain? That would eliminate the need for the lines 119-132.
> 
> I'd prefer as it is now, otherwise we have to add nested "if"s since we have 4
> combinations for (fixed_interface, aec_dum_input && simulate_gain).
> 
> Also, from a design perspective, either we pass all the parameters (i.e., undo
> mic level and mic level) to SimulateAnalogGain() or just the buffer to
process.
> 
> WDYT?

I would personally prefer to have it as one single call as it gives shorter code
and I don't think that would complicate anything.. But lets see how it turns out
with the changes done in response to the comment above.

https://codereview.webrtc.org/2834643002/diff/220001/webrtc/modules/audio_pro...
webrtc/modules/audio_processing/test/audio_processing_simulator.cc:147:
fake_recording_device_->mic_level()));
On 2017/06/29 11:43:35, AleBzk wrote:
> On 2017/06/29 05:45:27, peah-webrtc wrote:
> > This is something that I think complicates the code quite a bit. As I
> commented
> > on a previous patch, I don't think that the fake recording device should at
> all
> > be involved with the mic_level if the mic gain should not be simulated.
> > 
> > As it is now, it seems from this line as if the fake_recording_device is
> > choosing the mic level, instead of that the mic level in the aec_dump is
> passed.
> 
> What happens during a call is that AGC suggests a gain but for many different
> reasons, the suggestion can be overridden (e.g., the user manually sets the
mic
> gain via OS UI). I haven't verified if AGC makes use of the actual mic gain to
> suggest a new one or if it uses the sequence of suggested gains blindly.
That's
> why I think we'd better to tell AGC the actual mic gain.
> 
> I understand that you find this confusing, but this is an AGC API issue - and
in
> fact we planned to eliminate the "set_stream_analog_level, ProcessStream,
> stream_analog_level" sequence of invocations (error prone). My suggestion is
> that until the AGC API remains as it is, we keep this call, maybe adding more
> details in the comment.
> 
> WDYT?
> 
> > Furthermore, verifying that that is not the case is not that
straightforward.
> > 
> > Why not do as I proposed in a comment on a previous patch, and pass in 
> > *aec_dump_mic_level_ directly.
> 

You definitely need to pass the mic gain to the fake recording device when it is
used, as that is how the AGC operates. 

The concern I have is that you involve the fake recording device even when it is
not used, and to me that is confusing. What I meant with my comment is that I
want you to directly pass the gain that is stored in the recording (or rather
copied from the recording) . As it is now, the gain is copied into fakeaudio
device and then passed from that into the agc which gives the impression that
the fakeaudiodevice is involved, which it is not.

This change does not require any change in the AGC API.

https://codereview.webrtc.org/2834643002/diff/220001/webrtc/modules/audio_pro...
File webrtc/modules/audio_processing/test/fake_recording_device.cc (right):

https://codereview.webrtc.org/2834643002/diff/220001/webrtc/modules/audio_pro...
webrtc/modules/audio_processing/test/fake_recording_device.cc:21: // Abstract
class for the different fake recording devices.
On 2017/06/29 11:43:35, AleBzk wrote:
> On 2017/06/29 05:45:27, peah-webrtc wrote:
> > The scheme for the clipping and analog gain is quite intricate, but
regardless
> > of that I don't think it is general enough to scale. Therefore, I'd propose
> (as
> > I previously suggested) to have a much simpler implementation now until the
> real
> > simulation work of the recording device is started, as the implementation
> herein
> > is currently only a placeholder functionality for this.
> > 
> > My main concerns are the clipping. As it is now, that is hardcoded in the
> parent
> > class but we have discussed clipping solutions which don't comply to the
> scheme
> > that is hardcoded. How do you envision that to fit into the framework below?

> 
> Thanks for these concerns.
> 
> First, to improve the clarity, I moved constants and the hard clipping
functions
> in the anon namespace.
> It's good to have them somewhere to avoid code duplication.
> 
> Then note that each implementation of FakeRecordingDeviceWorker can implement
> its clipping strategy - not obliged to use ClipSampleInt16/ClipSampleFloat.
> Hence, I find the current design extremely flexible and also compact. In fact,
> FakeRecordingDeviceLinear::ModifySampleFloat() is just 5 lines of code excl.
> comments.
> 
> Also note that we need ModifySampleInt16/ModifySampleFloat mainly because of
the
> client code.
> Another way is to only implement the float interface and scale in [-2^15, 2^15
-
> 1] afterwards for int16.
> 
> With that being said, if you find that having moved code to the anon namespace
> is still insufficient, could you then be more specific when you say that we
> could have a much simpler implementation?

With simpler implementation, I rather mean less advanced, since it is yet to be
used and since the work on actually simulating this has not started, which means
it will anyway likely change.

For instance the following would be sufficient for the floating point, 
for (auto & x : float_sample_vector) {
  x = std::min(1.f, std::max(-1.f, mic_level/undo_mic_level));
}

https://codereview.webrtc.org/2834643002/diff/220001/webrtc/modules/audio_pro...
webrtc/modules/audio_processing/test/fake_recording_device.cc:123: [this](float&
x) { worker_->ModifySampleFloat(&x); });
On 2017/06/29 11:43:35, AleBzk wrote:
> On 2017/06/29 05:45:27, peah-webrtc wrote:
> > Why not pass the whole vector into ModifySampleFloat?
> 
> Just wanted to decouple FakeRecordingDeviceWorker implementations from a
buffer
> type (to avoid code duplication across the implementations).
> However, the overhead of a lambda invoked for each sample is not that nice
> either.
> 
> Thanks to your comments I realized that it's better to fully delegate
> FakeRecordingDeviceWorker implementations, since a simulated device may have
> memory and hence require a different way to iterate through the samples -
> depending on the specific buffer type. For instance, AudioFrame has
interleaved
> samples and therefore care must be taken if we want to simulate soft-clipping
> with memory.
> 
> WDYT?

I'd say do this as simple as possible now, as you'll anyway need to rewrite this
once the work on simulating the analog microphone starts.

https://codereview.webrtc.org/2834643002/diff/290001/webrtc/modules/audio_pro...
File webrtc/modules/audio_processing/test/aec_dump_based_simulator.cc (right):

https://codereview.webrtc.org/2834643002/diff/290001/webrtc/modules/audio_pro...
webrtc/modules/audio_processing/test/aec_dump_based_simulator.cc:72: << "(the
unmodified mic gain level will be virtually restored)";
This comment is not really fully correct,  right? It depends on what is done. If
another mic gain is specified, that will be implemented.

Why not just used the first log line. That should be sufficient for the user.

https://codereview.webrtc.org/2834643002/diff/290001/webrtc/modules/audio_pro...
File webrtc/modules/audio_processing/test/audio_processing_simulator.cc (right):

https://codereview.webrtc.org/2834643002/diff/290001/webrtc/modules/audio_pro...
webrtc/modules/audio_processing/test/audio_processing_simulator.cc:92: ?
static_cast<FakeRecordingDevice::DeviceKind>(
I think you should move the selection of DeviceKind into the
fake_recording_device. 
Having it here just constitutes a cast to something specified elsewhere and I
think the mapping between the parameter value and the actual DeviceKind would be
more clear if the DeviceKind and the mapping was done at the same place.

Please check the constructor for more comments.

https://codereview.webrtc.org/2834643002/diff/290001/webrtc/modules/audio_pro...
webrtc/modules/audio_processing/test/audio_processing_simulator.cc:120: if
(settings_.aec_dump_input_filename && settings_.simulate_mic_gain) {
This is better, but I'd rephrase it as

  if (settings_.simulate_mic_gain) {
     if (settings_.aec_dump_input_filename) { 
        RTC_DCHECK(aec_dump_mic_level_);
        fake_recording_device_.set_undo_mic_level(aec_dump_mic_level_);
     }
 
      if (fixed_interface) {
        fake_recording_device_.SimulateAnalogGain(&fwd_frame_);
      } else {
        fake_recording_device_.SimulateAnalogGain(in_buf_.get());
      }
    }

No need to have two different if-s on simulate_mic_gain

https://codereview.webrtc.org/2834643002/diff/290001/webrtc/modules/audio_pro...
webrtc/modules/audio_processing/test/audio_processing_simulator.cc:140:
ap_->gain_control()->set_stream_analog_level(
No, I don't think this is ok. The fake recording device should not be involved
if the microphone gain is not being simulated.

Furthermore, I doubt that this is correct now, as the  previous call to
set_mic_level was removed.

https://codereview.webrtc.org/2834643002/diff/290001/webrtc/modules/audio_pro...
File webrtc/modules/audio_processing/test/fake_recording_device.cc (right):

https://codereview.webrtc.org/2834643002/diff/290001/webrtc/modules/audio_pro...
webrtc/modules/audio_processing/test/fake_recording_device.cc:112:
FakeRecordingDevice::FakeRecordingDevice(int initial_mic_level, DeviceKind kind)
Having seen the usage of the constructor, I definitely think the comment about
the cast in the construction does not make sense.

As it is now, the constructor first converts the simulated_mic_kind into a
DeviceKind using a static_cast. 
     fake_recording_device_(settings.initial_mic_level,
                              settings_.simulate_mic_gain
                                   ?
static_cast<FakeRecordingDevice::DeviceKind>(
                                          *settings.simulated_mic_kind)
                                    : kDefaultFakeRecDeviceKind),

Then the resulting DeviceKind variable is only used in the constructor switch
statement.

I think you should simply pass settings.simulated_mic_kind into the constructor
and make the switch statement on that. That would be more direct, and would
require less code.

https://codereview.webrtc.org/2834643002/diff/290001/webrtc/modules/audio_pro...
File webrtc/modules/audio_processing/test/fake_recording_device.h (right):

https://codereview.webrtc.org/2834643002/diff/290001/webrtc/modules/audio_pro...
webrtc/modules/audio_processing/test/fake_recording_device.h:62:
rtc::Optional<int> undo_mic_level() const { return undo_mic_level_; }
This getter is never used. Please remove.
Sign in to reply to this message.

Powered by Google App Engine
RSS Feeds Recent Issues | This issue
This is Rietveld 25c286973