Miscellaneous changes split from https://codereview.webrtc.org/1230503003 .

Miscellaneous changes split from https://codereview.webrtc.org/1230503003 .

These are mostly trivial changes and are separated out just to reduce the
diff on that change to the minimum possible.

Note explanatory comments on patch set 1.

BUG=none
TEST=none

Committed: https://crrev.com/b297c5a01f88219da26cffe433804963d1b70f0f
Cr-Commit-Position: refs/heads/master@{#9617}

[Peter Kasting, 2015-07-10 18:48:44]

pkasting@chromium.org changed reviewers:
+ bjornv@webrtc.org, kwiberg@webrtc.org, niklas.enbom@webrtc.org

[Peter Kasting, 2015-07-10 18:48:46]

kwiberg: webrtc/modules/audio_coding/ OWNERS
niklas.enbom: webrtc/modules/audio_device/ OWNERS
bjornv: webrtc/common_audio/, webrtc/modules/audio_processing/ OWNERS

https://codereview.webrtc.org/1235643003/diff/1/webrtc/modules/audio_coding/c...
File webrtc/modules/audio_coding/codecs/ilbc/cb_mem_energy.h (right):

https://codereview.webrtc.org/1235643003/diff/1/webrtc/modules/audio_coding/c...
webrtc/modules/audio_coding/codecs/ilbc/cb_mem_energy.h:31: int16_t base_size 
/* (i) Index to where energy values should be stored */
(Line was over 80 columns)

https://codereview.webrtc.org/1235643003/diff/1/webrtc/modules/audio_coding/c...
File webrtc/modules/audio_coding/codecs/isac/fix/source/isacfix.c (right):

https://codereview.webrtc.org/1235643003/diff/1/webrtc/modules/audio_coding/c...
webrtc/modules/audio_coding/codecs/isac/fix/source/isacfix.c:1324: err =
WebRtcIsacfix_DecodeFrameLen(&streamdata, &frameLength);
This doesn't actually make a functional difference since in the case of error
the caller doesn't look at |rateIndex| anyway, and when there's no error it
would be overwritten below.  However, it's theoretically more correct, since the
frame length this call stores into the outparam has nothing to do with what
|rateIndex| was supposed to be set to.

https://codereview.webrtc.org/1235643003/diff/1/webrtc/modules/audio_coding/c...
File
webrtc/modules/audio_coding/codecs/isac/main/test/ReleaseTest-API/ReleaseTest-API.cc
(right):

https://codereview.webrtc.org/1235643003/diff/1/webrtc/modules/audio_coding/c...
webrtc/modules/audio_coding/codecs/isac/main/test/ReleaseTest-API/ReleaseTest-API.cc:667:
exit(0);
This matches the comment better and will also be necessary in the future when
the non-error case wants to store |stream_len| into a size_t (and therefore it
must not be negative).

https://codereview.webrtc.org/1235643003/diff/1/webrtc/modules/audio_coding/c...
File webrtc/modules/audio_coding/codecs/isac/main/test/simpleKenny.c (right):

https://codereview.webrtc.org/1235643003/diff/1/webrtc/modules/audio_coding/c...
webrtc/modules/audio_coding/codecs/isac/main/test/simpleKenny.c:357: }
Again, this is needed because we'll be stuffing |rcuStreamLen| into a size_t.

https://codereview.webrtc.org/1235643003/diff/1/webrtc/modules/audio_coding/n...
File webrtc/modules/audio_coding/neteq/dsp_helper.cc (right):

https://codereview.webrtc.org/1235643003/diff/1/webrtc/modules/audio_coding/n...
webrtc/modules/audio_coding/neteq/dsp_helper.cc:120: min_index = (peak_index[i]
> 2) ? (peak_index[i] - 2) : 0;
This form still works when |peak_index| becomes a size_t.

https://codereview.webrtc.org/1235643003/diff/1/webrtc/modules/audio_coding/n...
webrtc/modules/audio_coding/neteq/dsp_helper.cc:241: int best_index = 0;
This function should never have returned this value, since it could only occur
when min_lag > max_lag, and that's not the case at our callsite; so this should
make no functional difference.  The function will be changing to return a
size_t, so -1 wasn't a valid return value.

https://codereview.webrtc.org/1235643003/diff/1/webrtc/modules/audio_processi...
File webrtc/modules/audio_processing/beamformer/nonlinear_beamformer.cc (right):

https://codereview.webrtc.org/1235643003/diff/1/webrtc/modules/audio_processi...
webrtc/modules/audio_processing/beamformer/nonlinear_beamformer.cc:469: (1 -
kMaskFrequencySmoothAlpha) * final_mask_[i];
This form is safe against underflow if |i| becomes size_t.

https://codereview.webrtc.org/1235643003/diff/1/webrtc/modules/audio_processi...
File webrtc/modules/audio_processing/intelligibility/intelligibility_enhancer.cc
(right):

https://codereview.webrtc.org/1235643003/diff/1/webrtc/modules/audio_processi...
webrtc/modules/audio_processing/intelligibility/intelligibility_enhancer.cc:136:
start_freq_ = std::max(1, erb_index * erb_resolution);
It seemed strange to use the passed-in resolution most places but hardcode a
file-scope constant here.  Besides this, the caller actually passes the same
value (2) for the resolution anyway, so this won't actually have a practical
effect.

https://codereview.webrtc.org/1235643003/diff/1/webrtc/modules/audio_processi...
File webrtc/modules/audio_processing/intelligibility/intelligibility_proc.cc
(right):

https://codereview.webrtc.org/1235643003/diff/1/webrtc/modules/audio_processi...
webrtc/modules/audio_processing/intelligibility/intelligibility_proc.cc:40: }
This validator is necessary since we're going to want to store |clear_window| in
a size_t.

[niklas.enbom, 2015-07-11 07:41:12]

I'm out on vacation, so please use henrika@ for my parts.

On 2015/07/10 18:48:46, Peter Kasting wrote:
> kwiberg: webrtc/modules/audio_coding/ OWNERS
> niklas.enbom: webrtc/modules/audio_device/ OWNERS
> bjornv: webrtc/common_audio/, webrtc/modules/audio_processing/ OWNERS
> 
>
https://codereview.webrtc.org/1235643003/diff/1/webrtc/modules/audio_coding/c...
> File webrtc/modules/audio_coding/codecs/ilbc/cb_mem_energy.h (right):
> 
>
https://codereview.webrtc.org/1235643003/diff/1/webrtc/modules/audio_coding/c...
> webrtc/modules/audio_coding/codecs/ilbc/cb_mem_energy.h:31: int16_t base_size 
> /* (i) Index to where energy values should be stored */
> (Line was over 80 columns)
> 
>
https://codereview.webrtc.org/1235643003/diff/1/webrtc/modules/audio_coding/c...
> File webrtc/modules/audio_coding/codecs/isac/fix/source/isacfix.c (right):
> 
>
https://codereview.webrtc.org/1235643003/diff/1/webrtc/modules/audio_coding/c...
> webrtc/modules/audio_coding/codecs/isac/fix/source/isacfix.c:1324: err =
> WebRtcIsacfix_DecodeFrameLen(&streamdata, &frameLength);
> This doesn't actually make a functional difference since in the case of error
> the caller doesn't look at |rateIndex| anyway, and when there's no error it
> would be overwritten below.  However, it's theoretically more correct, since
the
> frame length this call stores into the outparam has nothing to do with what
> |rateIndex| was supposed to be set to.
> 
>
https://codereview.webrtc.org/1235643003/diff/1/webrtc/modules/audio_coding/c...
> File
>
webrtc/modules/audio_coding/codecs/isac/main/test/ReleaseTest-API/ReleaseTest-API.cc
> (right):
> 
>
https://codereview.webrtc.org/1235643003/diff/1/webrtc/modules/audio_coding/c...
>
webrtc/modules/audio_coding/codecs/isac/main/test/ReleaseTest-API/ReleaseTest-API.cc:667:
> exit(0);
> This matches the comment better and will also be necessary in the future when
> the non-error case wants to store |stream_len| into a size_t (and therefore it
> must not be negative).
> 
>
https://codereview.webrtc.org/1235643003/diff/1/webrtc/modules/audio_coding/c...
> File webrtc/modules/audio_coding/codecs/isac/main/test/simpleKenny.c (right):
> 
>
https://codereview.webrtc.org/1235643003/diff/1/webrtc/modules/audio_coding/c...
> webrtc/modules/audio_coding/codecs/isac/main/test/simpleKenny.c:357: }
> Again, this is needed because we'll be stuffing |rcuStreamLen| into a size_t.
> 
>
https://codereview.webrtc.org/1235643003/diff/1/webrtc/modules/audio_coding/n...
> File webrtc/modules/audio_coding/neteq/dsp_helper.cc (right):
> 
>
https://codereview.webrtc.org/1235643003/diff/1/webrtc/modules/audio_coding/n...
> webrtc/modules/audio_coding/neteq/dsp_helper.cc:120: min_index =
(peak_index[i]
> > 2) ? (peak_index[i] - 2) : 0;
> This form still works when |peak_index| becomes a size_t.
> 
>
https://codereview.webrtc.org/1235643003/diff/1/webrtc/modules/audio_coding/n...
> webrtc/modules/audio_coding/neteq/dsp_helper.cc:241: int best_index = 0;
> This function should never have returned this value, since it could only occur
> when min_lag > max_lag, and that's not the case at our callsite; so this
should
> make no functional difference.  The function will be changing to return a
> size_t, so -1 wasn't a valid return value.
> 
>
https://codereview.webrtc.org/1235643003/diff/1/webrtc/modules/audio_processi...
> File webrtc/modules/audio_processing/beamformer/nonlinear_beamformer.cc
(right):
> 
>
https://codereview.webrtc.org/1235643003/diff/1/webrtc/modules/audio_processi...
> webrtc/modules/audio_processing/beamformer/nonlinear_beamformer.cc:469: (1 -
> kMaskFrequencySmoothAlpha) * final_mask_[i];
> This form is safe against underflow if |i| becomes size_t.
> 
>
https://codereview.webrtc.org/1235643003/diff/1/webrtc/modules/audio_processi...
> File
webrtc/modules/audio_processing/intelligibility/intelligibility_enhancer.cc
> (right):
> 
>
https://codereview.webrtc.org/1235643003/diff/1/webrtc/modules/audio_processi...
>
webrtc/modules/audio_processing/intelligibility/intelligibility_enhancer.cc:136:
> start_freq_ = std::max(1, erb_index * erb_resolution);
> It seemed strange to use the passed-in resolution most places but hardcode a
> file-scope constant here.  Besides this, the caller actually passes the same
> value (2) for the resolution anyway, so this won't actually have a practical
> effect.
> 
>
https://codereview.webrtc.org/1235643003/diff/1/webrtc/modules/audio_processi...
> File webrtc/modules/audio_processing/intelligibility/intelligibility_proc.cc
> (right):
> 
>
https://codereview.webrtc.org/1235643003/diff/1/webrtc/modules/audio_processi...
> webrtc/modules/audio_processing/intelligibility/intelligibility_proc.cc:40: }
> This validator is necessary since we're going to want to store |clear_window|
in
> a size_t.

[Peter Kasting, 2015-07-11 08:30:16]

pkasting@chromium.org changed reviewers:
+ henrika@webrtc.org
- niklas.enbom@webrtc.org

[Peter Kasting, 2015-07-11 08:30:16]

->henrika for webrtc/modules/audio_device/ OWNERS

[kwiberg-webrtc, 2015-07-12 18:40:30]

https://codereview.webrtc.org/1235643003/diff/20001/webrtc/modules/audio_codi...
File webrtc/modules/audio_coding/codecs/isac/fix/source/decode.c (right):

https://codereview.webrtc.org/1235643003/diff/20001/webrtc/modules/audio_codi...
webrtc/modules/audio_coding/codecs/isac/fix/source/decode.c:32: int16_t
*current_framesamples)
Put * in the right place while you're at it?

https://codereview.webrtc.org/1235643003/diff/20001/webrtc/modules/audio_codi...
File webrtc/modules/audio_coding/codecs/isac/main/source/isac.c (right):

https://codereview.webrtc.org/1235643003/diff/20001/webrtc/modules/audio_codi...
webrtc/modules/audio_coding/codecs/isac/main/source/isac.c:754: (crc >> (24 - k
* 8)) & 0xFF;
Why the explicit & 0xff?

https://codereview.webrtc.org/1235643003/diff/20001/webrtc/modules/audio_codi...
File webrtc/modules/audio_coding/neteq/audio_decoder_impl.cc (right):

https://codereview.webrtc.org/1235643003/diff/20001/webrtc/modules/audio_codi...
webrtc/modules/audio_coding/neteq/audio_decoder_impl.cc:266: }
Hmm. Maybe better, but still messy. How about using const int16_t ret_left for
the first call, const int16_t ret_right for the second call, and eliminate
decoded_len altogether?

https://codereview.webrtc.org/1235643003/diff/20001/webrtc/modules/audio_codi...
File webrtc/modules/audio_coding/neteq/test/RTPencode.cc (right):

https://codereview.webrtc.org/1235643003/diff/20001/webrtc/modules/audio_codi...
webrtc/modules/audio_coding/neteq/test/RTPencode.cc:1585: if ((tempLen %
sampleRate_30) == 0) {  // tempLen is multiple of 30ms
I don't think this means the same thing as the old code. % and * and / have the
same precedence.

Hmm. But the comment indicates that the new code is how it was supposed to work.
Does the test succeed both with the old and the new code?

[Peter Kasting, 2015-07-13 02:41:25]

https://codereview.webrtc.org/1235643003/diff/20001/webrtc/modules/audio_codi...
File webrtc/modules/audio_coding/codecs/isac/main/source/isac.c (right):

https://codereview.webrtc.org/1235643003/diff/20001/webrtc/modules/audio_codi...
webrtc/modules/audio_coding/codecs/isac/main/source/isac.c:754: (crc >> (24 - k
* 8)) & 0xFF;
On 2015/07/12 at 18:40:30, kwiberg-webrtc wrote:
> Why the explicit & 0xff?

It should probably be a static_cast<uint8_t>() instead, now that I think about
it.

The goal was to eliminate MSVC "implicit cast could have truncated value"
warnings by making the truncation explicit, but doing that with a cast is better
than doing it with a mask.

https://codereview.webrtc.org/1235643003/diff/20001/webrtc/modules/audio_codi...
File webrtc/modules/audio_coding/neteq/audio_decoder_impl.cc (right):

https://codereview.webrtc.org/1235643003/diff/20001/webrtc/modules/audio_codi...
webrtc/modules/audio_coding/neteq/audio_decoder_impl.cc:266: }
On 2015/07/12 at 18:40:30, kwiberg-webrtc wrote:
> Hmm. Maybe better, but still messy. How about using const int16_t ret_left for
the first call, const int16_t ret_right for the second call, and eliminate
decoded_len altogether?

I don't think that makes life better, due to the way the code wants to clean up
below this and then return |ret|, which will take on different values depending
on the result of the comparison.

I'm also going to be modifying this further, since the underlying function will
start returning a size_t and thus the ">= 0" check will disappear.  I would
suggest going with this as an improvement for now and then taking a look when I
touch it again at whether it's been made as good as possible or can still be
improved further.

https://codereview.webrtc.org/1235643003/diff/20001/webrtc/modules/audio_codi...
File webrtc/modules/audio_coding/neteq/test/RTPencode.cc (right):

https://codereview.webrtc.org/1235643003/diff/20001/webrtc/modules/audio_codi...
webrtc/modules/audio_coding/neteq/test/RTPencode.cc:1585: if ((tempLen %
sampleRate_30) == 0) {  // tempLen is multiple of 30ms
On 2015/07/12 at 18:40:30, kwiberg-webrtc wrote:
> I don't think this means the same thing as the old code. % and * and / have
the same precedence.
> 
> Hmm. But the comment indicates that the new code is how it was supposed to
work. Does the test succeed both with the old and the new code?

Yes.  Which suggests the test is insufficient, since if the old code functions
differently I think it must be wrong.

[henrika_webrtc, 2015-07-13 08:07:27]

audio_device/ LGTM

[Peter Kasting, 2015-07-13 22:25:04]

https://codereview.webrtc.org/1235643003/diff/20001/webrtc/modules/audio_codi...
File webrtc/modules/audio_coding/codecs/isac/fix/source/decode.c (right):

https://codereview.webrtc.org/1235643003/diff/20001/webrtc/modules/audio_codi...
webrtc/modules/audio_coding/codecs/isac/fix/source/decode.c:32: int16_t
*current_framesamples)
On 2015/07/12 at 18:40:30, kwiberg-webrtc wrote:
> Put * in the right place while you're at it?

Done (here).

https://codereview.webrtc.org/1235643003/diff/20001/webrtc/modules/audio_codi...
File webrtc/modules/audio_coding/codecs/isac/main/source/isac.c (right):

https://codereview.webrtc.org/1235643003/diff/20001/webrtc/modules/audio_codi...
webrtc/modules/audio_coding/codecs/isac/main/source/isac.c:754: (crc >> (24 - k
* 8)) & 0xFF;
On 2015/07/13 at 02:41:24, Peter Kasting wrote:
> On 2015/07/12 at 18:40:30, kwiberg-webrtc wrote:
> > Why the explicit & 0xff?
> 
> It should probably be a static_cast<uint8_t>() instead, now that I think about
it.

Changed to a static_cast.

https://codereview.webrtc.org/1235643003/diff/20001/webrtc/modules/audio_codi...
File webrtc/modules/audio_coding/neteq/test/RTPencode.cc (right):

https://codereview.webrtc.org/1235643003/diff/20001/webrtc/modules/audio_codi...
webrtc/modules/audio_coding/neteq/test/RTPencode.cc:1585: if ((tempLen %
sampleRate_30) == 0) {  // tempLen is multiple of 30ms
On 2015/07/13 at 02:41:24, Peter Kasting wrote:
> On 2015/07/12 at 18:40:30, kwiberg-webrtc wrote:
> > I don't think this means the same thing as the old code. % and * and / have
the same precedence.
> > 
> > Hmm. But the comment indicates that the new code is how it was supposed to
work. Does the test succeed both with the old and the new code?
> 
> Yes.  Which suggests the test is insufficient, since if the old code functions
differently I think it must be wrong.

It looks to me as if the behavior of this code will differ in cases where the
packet size provided on the command line is a multiple of 30, but not a multiple
of (30 * sampleRate / 1000).  So for sampleRate == 10000, for example, a packet
size of 300 will behave the same as before, but 330 will not.

So the question is whether this test was ever being run with command-line
arguments that exercised that difference.  My guess is no, and thus the bug in
the old code was never detected.

[kwiberg-webrtc, 2015-07-15 01:10:53]

lgtm for webrtc/modules/audio_coding/

https://codereview.webrtc.org/1235643003/diff/20001/webrtc/modules/audio_codi...
File webrtc/modules/audio_coding/codecs/isac/main/source/isac.c (right):

https://codereview.webrtc.org/1235643003/diff/20001/webrtc/modules/audio_codi...
webrtc/modules/audio_coding/codecs/isac/main/source/isac.c:754: (crc >> (24 - k
* 8)) & 0xFF;
On 2015/07/13 22:25:04, Peter Kasting wrote:
> On 2015/07/13 at 02:41:24, Peter Kasting wrote:
> > On 2015/07/12 at 18:40:30, kwiberg-webrtc wrote:
> > > Why the explicit & 0xff?
> > 
> > It should probably be a static_cast<uint8_t>() instead, now that I think
about
> it.
> 
> Changed to a static_cast.

Excellent. (That you changed to a cast. A static_cast was maybe not such a good
idea... ;-) )

https://codereview.webrtc.org/1235643003/diff/20001/webrtc/modules/audio_codi...
File webrtc/modules/audio_coding/neteq/test/RTPencode.cc (right):

https://codereview.webrtc.org/1235643003/diff/20001/webrtc/modules/audio_codi...
webrtc/modules/audio_coding/neteq/test/RTPencode.cc:1585: if ((tempLen %
sampleRate_30) == 0) {  // tempLen is multiple of 30ms
On 2015/07/13 22:25:04, Peter Kasting wrote:
> On 2015/07/13 at 02:41:24, Peter Kasting wrote:
> > On 2015/07/12 at 18:40:30, kwiberg-webrtc wrote:
> > > I don't think this means the same thing as the old code. % and * and /
have
> the same precedence.
> > > 
> > > Hmm. But the comment indicates that the new code is how it was supposed to
> work. Does the test succeed both with the old and the new code?
> > 
> > Yes.  Which suggests the test is insufficient, since if the old code
functions
> differently I think it must be wrong.
> 
> It looks to me as if the behavior of this code will differ in cases where the
> packet size provided on the command line is a multiple of 30, but not a
multiple
> of (30 * sampleRate / 1000).  So for sampleRate == 10000, for example, a
packet
> size of 300 will behave the same as before, but 330 will not.
> 
> So the question is whether this test was ever being run with command-line
> arguments that exercised that difference.  My guess is no, and thus the bug in
> the old code was never detected.

OK. As long as it doesn't break the test, it can hardly be a change for the
worse.

[Peter Kasting, 2015-07-15 06:28:55]

pkasting@chromium.org changed reviewers:
+ andrew@webrtc.org

[Peter Kasting, 2015-07-15 06:28:56]

Adding andrew as alternate OWNER for webrtc/common_audio/,
webrtc/modules/audio_processing/ since bjornv hasn't responded.  Whichever of
you gets to it first...

[Peter Kasting, 2015-07-16 19:11:19]

pkasting@chromium.org changed reviewers:
+ aluebs@webrtc.org, jan.skoglund@webrtc.org
- bjornv@webrtc.org

[Peter Kasting, 2015-07-16 19:12:04]

Seems bjornv is gone.  More alternate owners:
aluebs: webrtc/modules/audio_processing/
jan.skoglund: webrtc/common_audio/

[aluebs-webrtc, 2015-07-16 21:03:39]

aluebs@webrtc.org changed reviewers:
+ ekmeyerson@webrtc.org, turaj@webrtc.org

[aluebs-webrtc, 2015-07-16 21:03:41]

audio_processing/* lgtm, except 2 places where I am not sure and would like
ekmeyerson or turaj to have look.

https://codereview.webrtc.org/1235643003/diff/60001/webrtc/modules/audio_proc...
File webrtc/modules/audio_processing/intelligibility/intelligibility_enhancer.cc
(right):

https://codereview.webrtc.org/1235643003/diff/60001/webrtc/modules/audio_proc...
webrtc/modules/audio_processing/intelligibility/intelligibility_enhancer.cc:134:
start_freq_ = std::max(1, erb_index * erb_resolution);
This looks right to me, but it will change the behavior. Could you please
double-check with ekmeyerson or turajs, they are working on this.

https://codereview.webrtc.org/1235643003/diff/60001/webrtc/modules/audio_proc...
File
webrtc/modules/audio_processing/intelligibility/test/intelligibility_proc.cc
(right):

https://codereview.webrtc.org/1235643003/diff/60001/webrtc/modules/audio_proc...
webrtc/modules/audio_processing/intelligibility/test/intelligibility_proc.cc:39:
return value >= 0;
Shouldn't this be >? I think it would be better if ekmeyerson or turajs have a
look at this.

[ekm, 2015-07-16 21:37:18]

intelligibility/* lgtm, except one minor fix aluebs pointed out.

https://codereview.webrtc.org/1235643003/diff/60001/webrtc/modules/audio_proc...
File webrtc/modules/audio_processing/intelligibility/intelligibility_enhancer.cc
(right):

https://codereview.webrtc.org/1235643003/diff/60001/webrtc/modules/audio_proc...
webrtc/modules/audio_processing/intelligibility/intelligibility_enhancer.cc:134:
start_freq_ = std::max(1, erb_index * erb_resolution);
On 2015/07/16 21:03:40, aluebs-webrtc wrote:
> This looks right to me, but it will change the behavior. Could you please
> double-check with ekmeyerson or turajs, they are working on this.

This is fine; still achieves the desired behavior. Note: We are reworking things
slightly differently in another CL (https://codereview.webrtc.org/1234463003/).

https://codereview.webrtc.org/1235643003/diff/60001/webrtc/modules/audio_proc...
File
webrtc/modules/audio_processing/intelligibility/test/intelligibility_proc.cc
(right):

https://codereview.webrtc.org/1235643003/diff/60001/webrtc/modules/audio_proc...
webrtc/modules/audio_processing/intelligibility/test/intelligibility_proc.cc:39:
return value >= 0;
On 2015/07/16 21:03:40, aluebs-webrtc wrote:
> Shouldn't this be >? I think it would be better if ekmeyerson or turajs have a
> look at this.

Yes, this should be >, since it will use arrays of this size.

[Peter Kasting, 2015-07-17 00:05:14]

https://codereview.webrtc.org/1235643003/diff/60001/webrtc/modules/audio_proc...
File
webrtc/modules/audio_processing/intelligibility/test/intelligibility_proc.cc
(right):

https://codereview.webrtc.org/1235643003/diff/60001/webrtc/modules/audio_proc...
webrtc/modules/audio_processing/intelligibility/test/intelligibility_proc.cc:39:
return value >= 0;
On 2015/07/16 at 21:37:18, ekm wrote:
> On 2015/07/16 21:03:40, aluebs-webrtc wrote:
> > Shouldn't this be >? I think it would be better if ekmeyerson or turajs have
a
> > look at this.
> 
> Yes, this should be >, since it will use arrays of this size.

Done.

[jks, 2015-07-22 14:03:15]

LGTM for common_audio

[Peter Kasting, 2015-07-22 20:32:53]

The CQ bit was checked by pkasting@chromium.org

[Peter Kasting, 2015-07-22 20:32:53]

The patchset sent to the CQ was uploaded after l-g-t-m from henrika@webrtc.org,
ekmeyerson@webrtc.org, kwiberg@webrtc.org, aluebs@webrtc.org,
jan.skoglund@webrtc.org
Link to the patchset: https://codereview.webrtc.org/1235643003/#ps100001 (title:
"Resync")

[commit-bot: I haz the power, 2015-07-22 20:33:04]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1235643003/100001

[commit-bot: I haz the power, 2015-07-22 22:17:27]

Committed patchset #6 (id:100001)

[commit-bot: I haz the power, 2015-07-22 22:17:32]

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