Misc. small cleanups

Misc. small cleanups.

* Better param names
* Avoid using negative values for (bogus) placeholder channel counts (mostly in tests).  Since channels will be changing to size_t, negative values will be illegal; it's sufficient to use 0 in these cases.
* Use arraysize()
* Use size_t for counting frames, samples, blocks, buffers, and bytes -- most of these are already size_t in most places, this just fixes some stragglers
* reinterpret_cast<int64_t>(void*) is not necessarily safe; use uintptr_t instead
* Remove unnecessary code, e.g. dead code, needlessly long/repetitive code, or function overrides that exactly match the base definition
* Fix indenting
* Use uint32_t for timestamps (matching how it's already a uint32_t in most places)
* Spelling
* RTC_CHECK_EQ(expected, actual)
* Rewrap
* Use .empty()
* Be more pedantic about matching int/int32_t/
* Remove pointless consts on input parameters to functions
* Add missing sanity checks

All this was found in the course of constructing https://codereview.webrtc.org/1316523002/ , and is being landed separately first.

BUG=none
TEST=none

Committed: https://crrev.com/25702cb1628941427fa55e528f53483f239ae011
Cr-Commit-Position: refs/heads/master@{#11191}

[Peter Kasting, 2015-12-28 16:29:25]

Description was changed from

==========
Misc. changes from https://codereview.webrtc.org/1316523002/

BUG=none
TEST=none
==========

to

==========
Misc. cleanup.

* Better param names
* Avoid using negative values for (bogus) placeholder channel counts (mostly in
tests).  Since channels will be changing to size_t, negative values will be
illegal; it's sufficient to use 0 in these cases.
* Use arraysize()
* Use size_t for counting frames, samples, blocks, buffers, and bytes -- most of
these are already size_t in most places, this just fixes some stragglers
* reinterpret_cast<int64_t>(void*) is not necessarily safe; use uintptr_t
instead
* Remove unnecessary code, e.g. dead code, needlessly long/repetitive code, or
function overrides that exactly match the base definition
* Fix indenting
* Use uint32_t for timestamps (matching how it's already a uint32_t in most
places)
* Spelling
* RTC_CHECK_EQ(expected, actual)
* Rewrap
* Use .empty()
* Be more pedantic about matching int/int32_t/
* Remove pointless consts on input parameters to functions
* Add missing sanity checks

All this was found in the course of constructing
https://codereview.webrtc.org/1316523002/ , and is being landed separately
first.

BUG=none
TEST=none
==========

[Peter Kasting, 2015-12-28 16:37:06]

Description was changed from

==========
Misc. cleanup.

* Better param names
* Avoid using negative values for (bogus) placeholder channel counts (mostly in
tests).  Since channels will be changing to size_t, negative values will be
illegal; it's sufficient to use 0 in these cases.
* Use arraysize()
* Use size_t for counting frames, samples, blocks, buffers, and bytes -- most of
these are already size_t in most places, this just fixes some stragglers
* reinterpret_cast<int64_t>(void*) is not necessarily safe; use uintptr_t
instead
* Remove unnecessary code, e.g. dead code, needlessly long/repetitive code, or
function overrides that exactly match the base definition
* Fix indenting
* Use uint32_t for timestamps (matching how it's already a uint32_t in most
places)
* Spelling
* RTC_CHECK_EQ(expected, actual)
* Rewrap
* Use .empty()
* Be more pedantic about matching int/int32_t/
* Remove pointless consts on input parameters to functions
* Add missing sanity checks

All this was found in the course of constructing
https://codereview.webrtc.org/1316523002/ , and is being landed separately
first.

BUG=none
TEST=none
==========

to

==========
Misc. small cleanups.

* Better param names
* Avoid using negative values for (bogus) placeholder channel counts (mostly in
tests).  Since channels will be changing to size_t, negative values will be
illegal; it's sufficient to use 0 in these cases.
* Use arraysize()
* Use size_t for counting frames, samples, blocks, buffers, and bytes -- most of
these are already size_t in most places, this just fixes some stragglers
* reinterpret_cast<int64_t>(void*) is not necessarily safe; use uintptr_t
instead
* Remove unnecessary code, e.g. dead code, needlessly long/repetitive code, or
function overrides that exactly match the base definition
* Fix indenting
* Use uint32_t for timestamps (matching how it's already a uint32_t in most
places)
* Spelling
* RTC_CHECK_EQ(expected, actual)
* Rewrap
* Use .empty()
* Be more pedantic about matching int/int32_t/
* Remove pointless consts on input parameters to functions
* Add missing sanity checks

All this was found in the course of constructing
https://codereview.webrtc.org/1316523002/ , and is being landed separately
first.

BUG=none
TEST=none
==========

[Peter Kasting, 2015-12-28 16:37:07]

pkasting@chromium.org changed reviewers:
+ henrik.lundin@webrtc.org, niklas.enbom@webrtc.org, perkj@webrtc.org,
tina.legrand@webrtc.org

[Peter Kasting, 2015-12-28 16:45:31]

henrik.lundin: webrtc/modules/audio_coding/, webrtc/modules/audio_processing/
OWNERS
niklas.enbom: webrtc/modules/audio_device/, webrtc/modules/media_file/ OWNERS
perkj: talk/, webrtc/system_wrappers/ OWNERS
tina.legrand: webrtc/audio/, webrtc/common_audio/ OWNERS

[henrika_webrtc, 2015-12-29 08:24:02]

Replacing niklas.enbom for webrtc/modules/audio_device/: LGTM

[the sun, 2016-01-07 09:37:07]

solenberg@webrtc.org changed reviewers:
+ solenberg@webrtc.org

[the sun, 2016-01-07 09:37:07]

Please do not create CLs that:
a) touch a lot of things
b) that are completely orthogonal

lgtm for webrtc/audio/

[Peter Kasting, 2016-01-07 09:44:43]

On 2016/01/07 09:37:07, the sun wrote:
> Please do not create CLs that:
> a) touch a lot of things
> b) that are completely orthogonal

In some cases, I think it's significantly less work for both author and
reviewers to handle a conglomerate CL than a series of dozens of smaller ones. 
Especially when the author has an incredibly large and complex CL that's been in
the works for six months or so, keeping it compiling against trunk in the
author's spare time, that's blocked on getting all this in, and from which this
has been painfully extracted with hours of work :/

Also, not all of this is orthogonal; in particular there are a lot of size_t
changes that need to go together.

[perkj_webrtc, 2016-01-07 09:47:05]

system/wrappers lgtm
talk lgtm with a request.

https://codereview.webrtc.org/1534193008/diff/40001/talk/media/base/codec.h
File talk/media/base/codec.h (right):

https://codereview.webrtc.org/1534193008/diff/40001/talk/media/base/codec.h#n...
talk/media/base/codec.h:134: AudioCodec(int id,
This no longer match VideoCodec below. Would you mind fixing that too to make
the file style consistent.

[Peter Kasting, 2016-01-07 09:48:36]

https://codereview.webrtc.org/1534193008/diff/40001/talk/media/base/codec.h
File talk/media/base/codec.h (right):

https://codereview.webrtc.org/1534193008/diff/40001/talk/media/base/codec.h#n...
talk/media/base/codec.h:134: AudioCodec(int id,
On 2016/01/07 09:47:05, perkj_webrtc wrote:
> This no longer match VideoCodec below. Would you mind fixing that too to make
> the file style consistent. 

Yeah, I can fix that.

[Peter Kasting, 2016-01-07 09:55:09]

On 2016/01/07 09:44:43, Peter Kasting wrote:
> On 2016/01/07 09:37:07, the sun wrote:
> > Please do not create CLs that:
> > a) touch a lot of things
> > b) that are completely orthogonal
> 
> In some cases, I think it's significantly less work for both author and
> reviewers to handle a conglomerate CL than a series of dozens of smaller ones.

> Especially when the author has an incredibly large and complex CL that's been
in
> the works for six months or so, keeping it compiling against trunk in the
> author's spare time, that's blocked on getting all this in, and from which
this
> has been painfully extracted with hours of work :/
> 
> Also, not all of this is orthogonal; in particular there are a lot of size_t
> changes that need to go together.

(Sorry, this all sounds a bit combative; I agree very much with the spirit of
trying to keep things reviewable, and meant more to explain why I had
intentionally done things this way as an attempt to get the right tradeoff of
time invested on all parts.)

[the sun, 2016-01-07 10:39:49]

On 2016/01/07 09:55:09, Peter Kasting wrote:
> On 2016/01/07 09:44:43, Peter Kasting wrote:
> > On 2016/01/07 09:37:07, the sun wrote:
> > > Please do not create CLs that:
> > > a) touch a lot of things
> > > b) that are completely orthogonal
> > 
> > In some cases, I think it's significantly less work for both author and
> > reviewers to handle a conglomerate CL than a series of dozens of smaller
ones.
> 
> > Especially when the author has an incredibly large and complex CL that's
been
> in
> > the works for six months or so, keeping it compiling against trunk in the
> > author's spare time, that's blocked on getting all this in, and from which
> this
> > has been painfully extracted with hours of work :/
> > 
> > Also, not all of this is orthogonal; in particular there are a lot of size_t
> > changes that need to go together.
> 
> (Sorry, this all sounds a bit combative; I agree very much with the spirit of
> trying to keep things reviewable, and meant more to explain why I had
> intentionally done things this way as an attempt to get the right tradeoff of
> time invested on all parts.)

Sorry if I came off combative as well. Thanks for taking the time to do these
cleanups. Even minor things stick out when reading the code so it is important
to improve; broken windows theory and such.

[hlundin-webrtc, 2016-01-07 10:57:06]

LG, but please see my two questions?

https://codereview.webrtc.org/1534193008/diff/40001/webrtc/modules/audio_proc...
File webrtc/modules/audio_processing/beamformer/nonlinear_beamformer.cc (right):

https://codereview.webrtc.org/1534193008/diff/40001/webrtc/modules/audio_proc...
webrtc/modules/audio_processing/beamformer/nonlinear_beamformer.cc:415:
RTC_CHECK_EQ(kNumFreqBins, num_freq_bins);
Does the order of the arguments matter for CHECK? I know it produces nicer
print-outs for gtest's EXPECT_EQ, but what is the rationale here?

https://codereview.webrtc.org/1534193008/diff/40001/webrtc/modules/audio_proc...
File webrtc/modules/audio_processing/test/audio_processing_unittest.cc (right):

https://codereview.webrtc.org/1534193008/diff/40001/webrtc/modules/audio_proc...
webrtc/modules/audio_processing/test/audio_processing_unittest.cc:54: const
google::protobuf::int32 kChannels[] = {1, 2};
Why?

[hlundin-webrtc, 2016-01-07 11:00:06]

LGTM, with one question still unanswered.

https://codereview.webrtc.org/1534193008/diff/40001/webrtc/modules/audio_proc...
File webrtc/modules/audio_processing/test/audio_processing_unittest.cc (right):

https://codereview.webrtc.org/1534193008/diff/40001/webrtc/modules/audio_proc...
webrtc/modules/audio_processing/test/audio_processing_unittest.cc:54: const
google::protobuf::int32 kChannels[] = {1, 2};
On 2016/01/07 10:57:06, hlundin-OOO-to-Jan7 wrote:
> Why?

OK, I see why. Never mind.

[Peter Kasting, 2016-01-07 12:14:13]

https://codereview.webrtc.org/1534193008/diff/40001/webrtc/modules/audio_proc...
File webrtc/modules/audio_processing/beamformer/nonlinear_beamformer.cc (right):

https://codereview.webrtc.org/1534193008/diff/40001/webrtc/modules/audio_proc...
webrtc/modules/audio_processing/beamformer/nonlinear_beamformer.cc:415:
RTC_CHECK_EQ(kNumFreqBins, num_freq_bins);
On 2016/01/07 10:57:06, hlundin-OOO-to-Jan7 wrote:
> Does the order of the arguments matter for CHECK? I know it produces nicer
> print-outs for gtest's EXPECT_EQ, but what is the rationale here?

Examining the source code, it looks like it doesn't matter for these specific
macros; the macros just treat the args as "val1" and "val2".

At least some of us in Chromium have been in the habit of always using
(expected, actual) ordering for _EQ and _NE macros of any type, so as to simply
be consistent and not have to think about which type of checking macro is in
use.  (Which is part of why I didn't know the answer to your question without
reading the source.)  Whether you find that rationale compelling here is up to
you.  If not, I can revert these changes.  Let me know.

[hlundin-webrtc, 2016-01-07 12:24:32]

https://codereview.webrtc.org/1534193008/diff/40001/webrtc/modules/audio_proc...
File webrtc/modules/audio_processing/beamformer/nonlinear_beamformer.cc (right):

https://codereview.webrtc.org/1534193008/diff/40001/webrtc/modules/audio_proc...
webrtc/modules/audio_processing/beamformer/nonlinear_beamformer.cc:415:
RTC_CHECK_EQ(kNumFreqBins, num_freq_bins);
On 2016/01/07 12:14:13, Peter Kasting wrote:
> On 2016/01/07 10:57:06, hlundin-OOO-to-Jan7 wrote:
> > Does the order of the arguments matter for CHECK? I know it produces nicer
> > print-outs for gtest's EXPECT_EQ, but what is the rationale here?
> 
> Examining the source code, it looks like it doesn't matter for these specific
> macros; the macros just treat the args as "val1" and "val2".
> 
> At least some of us in Chromium have been in the habit of always using
> (expected, actual) ordering for _EQ and _NE macros of any type, so as to
simply
> be consistent and not have to think about which type of checking macro is in
> use.  (Which is part of why I didn't know the answer to your question without
> reading the source.)  Whether you find that rationale compelling here is up to
> you.  If not, I can revert these changes.  Let me know.

Either is fine.

[tlegrand-webrtc, 2016-01-07 12:47:52]

LGTM for webrtc/common_audio.
I'm skipping webrtc/audio, since Solenberg already reviewed those files.

I marked a few places where it might be possible to change to size_t (mostly
"number of channels"). There is probably a good reason for not changing those
now, but I wanted to bring it to your attention in case you just missed them.

https://codereview.webrtc.org/1534193008/diff/40001/webrtc/common_audio/audio...
File webrtc/common_audio/audio_converter_unittest.cc (right):

https://codereview.webrtc.org/1534193008/diff/40001/webrtc/common_audio/audio...
webrtc/common_audio/audio_converter_unittest.cc:29: const int num_channels =
static_cast<int>(data.size());
size_t?

https://codereview.webrtc.org/1534193008/diff/40001/webrtc/common_audio/block...
File webrtc/common_audio/blocker_unittest.cc (right):

https://codereview.webrtc.org/1534193008/diff/40001/webrtc/common_audio/block...
webrtc/common_audio/blocker_unittest.cc:86: int num_channels,
size_t? Same for the other "num_channels" in this file.

https://codereview.webrtc.org/1534193008/diff/40001/webrtc/common_audio/lappe...
File webrtc/common_audio/lapped_transform_unittest.cc (right):

https://codereview.webrtc.org/1534193008/diff/40001/webrtc/common_audio/lappe...
webrtc/common_audio/lapped_transform_unittest.cc:28: int in_channels,
size_t?

https://codereview.webrtc.org/1534193008/diff/40001/webrtc/common_audio/lappe...
webrtc/common_audio/lapped_transform_unittest.cc:30: int out_channels,
size_t?

https://codereview.webrtc.org/1534193008/diff/40001/webrtc/common_audio/lappe...
webrtc/common_audio/lapped_transform_unittest.cc:93: const int kChannels = 3;
size_t?

https://codereview.webrtc.org/1534193008/diff/40001/webrtc/common_audio/wav_f...
File webrtc/common_audio/wav_file.h (right):

https://codereview.webrtc.org/1534193008/diff/40001/webrtc/common_audio/wav_f...
webrtc/common_audio/wav_file.h:30: virtual int num_channels() const = 0;
size_t?

[Peter Kasting, 2016-01-07 13:16:57]

On 2016/01/07 12:47:52, tlegrand-webrtc wrote:
> LGTM for webrtc/common_audio.
> I'm skipping webrtc/audio, since Solenberg already reviewed those files.
> 
> I marked a few places where it might be possible to change to size_t (mostly
> "number of channels"). There is probably a good reason for not changing those
> now, but I wanted to bring it to your attention in case you just missed them.

You're prefiguring https://codereview.webrtc.org/1316523002/ :)

[niklas.enbom, 2016-01-07 20:16:46]

missed that I was still on the hook for media_file, sorry for the delay.

https://codereview.webrtc.org/1534193008/diff/40001/webrtc/modules/media_file...
File webrtc/modules/media_file/media_file_utility.cc (right):

https://codereview.webrtc.org/1534193008/diff/40001/webrtc/modules/media_file...
webrtc/modules/media_file/media_file_utility.cc:130: if
(CHUNKheaderObj.fmt_ckSize < 0)
Chunk Size in wav header is an unsigned int and can use the full range afaik.
_dataSize was incorrect already before your CL, but this might be a good time to
fix it.

[Peter Kasting, 2016-01-07 21:35:05]

https://codereview.webrtc.org/1534193008/diff/40001/webrtc/modules/media_file...
File webrtc/modules/media_file/media_file_utility.cc (right):

https://codereview.webrtc.org/1534193008/diff/40001/webrtc/modules/media_file...
webrtc/modules/media_file/media_file_utility.cc:130: if
(CHUNKheaderObj.fmt_ckSize < 0)
On 2016/01/07 20:16:46, niklas.enbom wrote:
> Chunk Size in wav header is an unsigned int and can use the full range afaik.
> _dataSize was incorrect already before your CL, but this might be a good time
to
> fix it. 

So, to be clear, are you suggesting I remove this conditional, remove the
(int32_t) cast above, and change .fmt_ckSize to uint32_t?

[niklas.enbom, 2016-01-07 21:50:36]

https://codereview.webrtc.org/1534193008/diff/40001/webrtc/modules/media_file...
File webrtc/modules/media_file/media_file_utility.cc (right):

https://codereview.webrtc.org/1534193008/diff/40001/webrtc/modules/media_file...
webrtc/modules/media_file/media_file_utility.cc:130: if
(CHUNKheaderObj.fmt_ckSize < 0)
That was my suggestion yes, but I haven't looked at how many other changes that
would lead to. It seems like it has been like this forever, so I'm fine with
just making the log clearer.

On 2016/01/07 21:35:05, Peter Kasting wrote:
> On 2016/01/07 20:16:46, niklas.enbom wrote:
> > Chunk Size in wav header is an unsigned int and can use the full range
afaik.
> > _dataSize was incorrect already before your CL, but this might be a good
time
> to
> > fix it. 
> 
> So, to be clear, are you suggesting I remove this conditional, remove the
> (int32_t) cast above, and change .fmt_ckSize to uint32_t?

[Peter Kasting, 2016-01-08 01:36:27]

Niklas: PTAL

https://codereview.webrtc.org/1534193008/diff/40001/talk/media/base/codec.h
File talk/media/base/codec.h (right):

https://codereview.webrtc.org/1534193008/diff/40001/talk/media/base/codec.h#n...
talk/media/base/codec.h:134: AudioCodec(int id,
On 2016/01/07 09:48:36, Peter Kasting wrote:
> On 2016/01/07 09:47:05, perkj_webrtc wrote:
> > This no longer match VideoCodec below. Would you mind fixing that too to
make
> > the file style consistent. 
> 
> Yeah, I can fix that.

Done.

https://codereview.webrtc.org/1534193008/diff/40001/webrtc/modules/media_file...
File webrtc/modules/media_file/media_file_utility.cc (right):

https://codereview.webrtc.org/1534193008/diff/40001/webrtc/modules/media_file...
webrtc/modules/media_file/media_file_utility.cc:130: if
(CHUNKheaderObj.fmt_ckSize < 0)
On 2016/01/07 21:50:36, niklas.enbom wrote:
> That was my suggestion yes, but I haven't looked at how many other changes
that
> would lead to. It seems like it has been like this forever, so I'm fine with
> just making the log clearer.

I made the change.  As you suspected, this value is unsigned rather than signed
(I checked the specs as well as other WebRTC WAV-reading code).  In making this
change I cleaned up a few other issues in this file as well; look at the diff
for the latest patchset.

[niklas.enbom, 2016-01-08 17:37:57]

media_file lgtm
On 2016/01/08 01:36:27, Peter Kasting wrote:
> Niklas: PTAL
> 
> https://codereview.webrtc.org/1534193008/diff/40001/talk/media/base/codec.h
> File talk/media/base/codec.h (right):
> 
>
https://codereview.webrtc.org/1534193008/diff/40001/talk/media/base/codec.h#n...
> talk/media/base/codec.h:134: AudioCodec(int id,
> On 2016/01/07 09:48:36, Peter Kasting wrote:
> > On 2016/01/07 09:47:05, perkj_webrtc wrote:
> > > This no longer match VideoCodec below. Would you mind fixing that too to
> make
> > > the file style consistent. 
> > 
> > Yeah, I can fix that.
> 
> Done.
> 
>
https://codereview.webrtc.org/1534193008/diff/40001/webrtc/modules/media_file...
> File webrtc/modules/media_file/media_file_utility.cc (right):
> 
>
https://codereview.webrtc.org/1534193008/diff/40001/webrtc/modules/media_file...
> webrtc/modules/media_file/media_file_utility.cc:130: if
> (CHUNKheaderObj.fmt_ckSize < 0)
> On 2016/01/07 21:50:36, niklas.enbom wrote:
> > That was my suggestion yes, but I haven't looked at how many other changes
> that
> > would lead to. It seems like it has been like this forever, so I'm fine with
> > just making the log clearer.
> 
> I made the change.  As you suspected, this value is unsigned rather than
signed
> (I checked the specs as well as other WebRTC WAV-reading code).  In making
this
> change I cleaned up a few other issues in this file as well; look at the diff
> for the latest patchset.

[Peter Kasting, 2016-01-08 21:27:01]

The CQ bit was checked by pkasting@chromium.org

[Peter Kasting, 2016-01-08 21:27:01]

The patchset sent to the CQ was uploaded after l-g-t-m from henrika@webrtc.org,
tina.legrand@webrtc.org, henrik.lundin@webrtc.org, solenberg@webrtc.org,
perkj@webrtc.org
Link to the patchset: https://codereview.chromium.org/1534193008/#ps80001
(title: "Unnecessary parens")

[commit-bot: I haz the power, 2016-01-08 21:27:13]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1534193008/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1534193008/80001

[commit-bot: I haz the power, 2016-01-08 21:50:31]

Description was changed from

==========
Misc. small cleanups.

* Better param names
* Avoid using negative values for (bogus) placeholder channel counts (mostly in
tests).  Since channels will be changing to size_t, negative values will be
illegal; it's sufficient to use 0 in these cases.
* Use arraysize()
* Use size_t for counting frames, samples, blocks, buffers, and bytes -- most of
these are already size_t in most places, this just fixes some stragglers
* reinterpret_cast<int64_t>(void*) is not necessarily safe; use uintptr_t
instead
* Remove unnecessary code, e.g. dead code, needlessly long/repetitive code, or
function overrides that exactly match the base definition
* Fix indenting
* Use uint32_t for timestamps (matching how it's already a uint32_t in most
places)
* Spelling
* RTC_CHECK_EQ(expected, actual)
* Rewrap
* Use .empty()
* Be more pedantic about matching int/int32_t/
* Remove pointless consts on input parameters to functions
* Add missing sanity checks

All this was found in the course of constructing
https://codereview.webrtc.org/1316523002/ , and is being landed separately
first.

BUG=none
TEST=none
==========

to

==========
Misc. small cleanups.

* Better param names
* Avoid using negative values for (bogus) placeholder channel counts (mostly in
tests).  Since channels will be changing to size_t, negative values will be
illegal; it's sufficient to use 0 in these cases.
* Use arraysize()
* Use size_t for counting frames, samples, blocks, buffers, and bytes -- most of
these are already size_t in most places, this just fixes some stragglers
* reinterpret_cast<int64_t>(void*) is not necessarily safe; use uintptr_t
instead
* Remove unnecessary code, e.g. dead code, needlessly long/repetitive code, or
function overrides that exactly match the base definition
* Fix indenting
* Use uint32_t for timestamps (matching how it's already a uint32_t in most
places)
* Spelling
* RTC_CHECK_EQ(expected, actual)
* Rewrap
* Use .empty()
* Be more pedantic about matching int/int32_t/
* Remove pointless consts on input parameters to functions
* Add missing sanity checks

All this was found in the course of constructing
https://codereview.webrtc.org/1316523002/ , and is being landed separately
first.

BUG=none
TEST=none
==========

[commit-bot: I haz the power, 2016-01-08 21:50:32]

Committed patchset #5 (id:80001)

[commit-bot: I haz the power, 2016-01-08 21:50:37]

Description was changed from

==========
Misc. small cleanups.

* Better param names
* Avoid using negative values for (bogus) placeholder channel counts (mostly in
tests).  Since channels will be changing to size_t, negative values will be
illegal; it's sufficient to use 0 in these cases.
* Use arraysize()
* Use size_t for counting frames, samples, blocks, buffers, and bytes -- most of
these are already size_t in most places, this just fixes some stragglers
* reinterpret_cast<int64_t>(void*) is not necessarily safe; use uintptr_t
instead
* Remove unnecessary code, e.g. dead code, needlessly long/repetitive code, or
function overrides that exactly match the base definition
* Fix indenting
* Use uint32_t for timestamps (matching how it's already a uint32_t in most
places)
* Spelling
* RTC_CHECK_EQ(expected, actual)
* Rewrap
* Use .empty()
* Be more pedantic about matching int/int32_t/
* Remove pointless consts on input parameters to functions
* Add missing sanity checks

All this was found in the course of constructing
https://codereview.webrtc.org/1316523002/ , and is being landed separately
first.

BUG=none
TEST=none
==========

to

==========
Misc. small cleanups.

* Better param names
* Avoid using negative values for (bogus) placeholder channel counts (mostly in
tests).  Since channels will be changing to size_t, negative values will be
illegal; it's sufficient to use 0 in these cases.
* Use arraysize()
* Use size_t for counting frames, samples, blocks, buffers, and bytes -- most of
these are already size_t in most places, this just fixes some stragglers
* reinterpret_cast<int64_t>(void*) is not necessarily safe; use uintptr_t
instead
* Remove unnecessary code, e.g. dead code, needlessly long/repetitive code, or
function overrides that exactly match the base definition
* Fix indenting
* Use uint32_t for timestamps (matching how it's already a uint32_t in most
places)
* Spelling
* RTC_CHECK_EQ(expected, actual)
* Rewrap
* Use .empty()
* Be more pedantic about matching int/int32_t/
* Remove pointless consts on input parameters to functions
* Add missing sanity checks

All this was found in the course of constructing
https://codereview.webrtc.org/1316523002/ , and is being landed separately
first.

BUG=none
TEST=none

Committed: https://crrev.com/25702cb1628941427fa55e528f53483f239ae011
Cr-Commit-Position: refs/heads/master@{#11191}
==========

[commit-bot: I haz the power, 2016-01-08 21:50:38]

Patchset 5 (id:??) landed as
https://crrev.com/25702cb1628941427fa55e528f53483f239ae011
Cr-Commit-Position: refs/heads/master@{#11191}