Simplifying audio network adaptor by moving receiver frame length range to ctor.

Simplifying audio network adaptor by moving receiver frame length range to ctor.

It turns out that that audio network adaptor can always be created with knowledge of receiver frame length range. There is no need to keep some infrastructure that is used for runtime setting of receiver frame length ranges.

BUG=webrtc:6303
Committed: https://crrev.com/a6f495c7c20e8b5ae33766ebbb1265ba14389e5a
Cr-Commit-Position: refs/heads/master@{#14748}

[minyue-webrtc, 2016-10-17 14:07:13]

Description was changed from

==========
Simplifying audio network adaptor by moving receiver frame length range to ctor.

BUG=webrtc:6303
==========

to

==========
Simplifying audio network adaptor by moving receiver frame length range to ctor.

BUG=webrtc:6303
==========

[minyue-webrtc, 2016-10-17 14:07:13]

minyue@webrtc.org changed reviewers:
+ michaelt@webrtc.org

[minyue-webrtc, 2016-10-17 14:08:41]

Hi Michael,

Would you take a look at this CL?

[minyue-webrtc, 2016-10-17 14:28:18]

Patchset #1 (id:1) has been deleted

[minyue-webrtc, 2016-10-17 14:28:35]

The CQ bit was checked by minyue@webrtc.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-17 14:28:40]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...

[commit-bot: I haz the power, 2016-10-17 14:34:31]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-17 14:34:32]

Dry run: Try jobs failed on following builders:
  linux_baremetal on master.tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/linux_baremetal/builds/...)

[michaelt, 2016-10-18 08:25:23]

https://codereview.webrtc.org/2429503002/diff/20001/webrtc/modules/audio_codi...
File
webrtc/modules/audio_coding/audio_network_adaptor/frame_length_controller.cc
(right):

https://codereview.webrtc.org/2429503002/diff/20001/webrtc/modules/audio_codi...
webrtc/modules/audio_coding/audio_network_adaptor/frame_length_controller.cc:40:
frame_length_ms_ = std::find(config_.encoder_frame_lengths_ms.begin(),
encoder_frame_lengths_ms seams not a fitting name any more.

https://codereview.webrtc.org/2429503002/diff/20001/webrtc/modules/audio_codi...
File webrtc/modules/audio_coding/codecs/opus/audio_encoder_opus.cc (right):

https://codereview.webrtc.org/2429503002/diff/20001/webrtc/modules/audio_codi...
webrtc/modules/audio_coding/codecs/opus/audio_encoder_opus.cc:451:
std::vector<int> frame_lengths;
Would be nice to have a unit-test for this functionality.

[minyue-webrtc, 2016-10-18 12:04:03]

Patchset #2 (id:40001) has been deleted

[minyue-webrtc, 2016-10-18 12:10:06]

Description was changed from

==========
Simplifying audio network adaptor by moving receiver frame length range to ctor.

BUG=webrtc:6303
==========

to

==========
Simplifying audio network adaptor by moving receiver frame length range to ctor.

It turns out that that audio network adaptor can always be created with
knowledge of receiver frame length range. There is no need to keep some
infrastructure that is used for runtime setting of receiver frame length ranges.

BUG=webrtc:6303
==========

[minyue-webrtc, 2016-10-18 12:13:21]

Patchset #2 (id:60001) has been deleted

[minyue-webrtc, 2016-10-18 13:25:13]

Hi Michael,

I updated the CL by not touching the AudioEncoder APIs, which makes better
sense, and bonus is that it allows me to test it. PTAL again.

https://codereview.webrtc.org/2429503002/diff/20001/webrtc/modules/audio_codi...
File
webrtc/modules/audio_coding/audio_network_adaptor/frame_length_controller.cc
(right):

https://codereview.webrtc.org/2429503002/diff/20001/webrtc/modules/audio_codi...
webrtc/modules/audio_coding/audio_network_adaptor/frame_length_controller.cc:40:
frame_length_ms_ = std::find(config_.encoder_frame_lengths_ms.begin(),
On 2016/10/18 08:25:23, michaelt wrote:
> encoder_frame_lengths_ms seams not a fitting name any more.

I think the name is still fine. Since the validation of frame length against
receiver's acceptable frame lengths becomes a job of AudioEncoder, ANA does not
need to be aware of any receiver concept. So it is indeed frame lengths that
"encoder" can accept for sending.

https://codereview.webrtc.org/2429503002/diff/20001/webrtc/modules/audio_codi...
File webrtc/modules/audio_coding/codecs/opus/audio_encoder_opus.cc (right):

https://codereview.webrtc.org/2429503002/diff/20001/webrtc/modules/audio_codi...
webrtc/modules/audio_coding/codecs/opus/audio_encoder_opus.cc:451:
std::vector<int> frame_lengths;
On 2016/10/18 08:25:23, michaelt wrote:
> Would be nice to have a unit-test for this functionality. 

I agree. I thought about it but did not find a good way to test. Thanks for
pushing this. Now I have one.

[minyue-webrtc, 2016-10-18 14:59:54]

minyue@webrtc.org changed reviewers:
+ kwiberg@webrtc.org

[minyue-webrtc, 2016-10-18 15:00:57]

Hi Karl,

Would you help review this CL. Michael has taken a look and thought it was good.

[kwiberg-webrtc, 2016-10-19 09:12:01]

Excellent improvement, but I have some questions.

https://codereview.webrtc.org/2429503002/diff/80001/webrtc/modules/audio_codi...
File webrtc/modules/audio_coding/audio_network_adaptor/controller_manager.cc
(right):

https://codereview.webrtc.org/2429503002/diff/80001/webrtc/modules/audio_codi...
webrtc/modules/audio_coding/audio_network_adaptor/controller_manager.cc:145:
const std::vector<int>& encoder_frame_lengths_ms,
Why did you make this change?

https://codereview.webrtc.org/2429503002/diff/80001/webrtc/modules/audio_codi...
File webrtc/modules/audio_coding/audio_network_adaptor/frame_length_controller.h
(right):

https://codereview.webrtc.org/2429503002/diff/80001/webrtc/modules/audio_codi...
webrtc/modules/audio_coding/audio_network_adaptor/frame_length_controller.h:76:
std::vector<int>::const_iterator frame_length_ms_;
Wait, what vector does this iterator point into?

https://codereview.webrtc.org/2429503002/diff/80001/webrtc/modules/audio_codi...
File webrtc/modules/audio_coding/codecs/opus/audio_encoder_opus.cc (right):

https://codereview.webrtc.org/2429503002/diff/80001/webrtc/modules/audio_codi...
webrtc/modules/audio_coding/codecs/opus/audio_encoder_opus.cc:310:
kSupportedFrameLengths + arraysize(kSupportedFrameLengths),
You should be able to use std::begin(kSupportedFrameLengths) and
std::end(kSupportedFrameLengths).

https://codereview.webrtc.org/2429503002/diff/80001/webrtc/modules/audio_codi...
File webrtc/modules/audio_coding/codecs/opus/audio_encoder_opus.h (right):

https://codereview.webrtc.org/2429503002/diff/80001/webrtc/modules/audio_codi...
webrtc/modules/audio_coding/codecs/opus/audio_encoder_opus.h:106: const
std::vector<int>& supported_frame_lengths_ms() const {
Again, I wonder if the return type here shouldn't be rtc::ArrayView<const int>.

[minyue-webrtc, 2016-10-19 09:25:54]

Hi Karl,

Thanks for the comments! See my reply inline.

https://codereview.webrtc.org/2429503002/diff/80001/webrtc/modules/audio_codi...
File webrtc/modules/audio_coding/audio_network_adaptor/controller_manager.cc
(right):

https://codereview.webrtc.org/2429503002/diff/80001/webrtc/modules/audio_codi...
webrtc/modules/audio_coding/audio_network_adaptor/controller_manager.cc:145:
const std::vector<int>& encoder_frame_lengths_ms,
On 2016/10/19 09:12:01, kwiberg-webrtc wrote:
> Why did you make this change?

Because it is easier to construct a vector at the current caller.

https://codereview.webrtc.org/2429503002/diff/80001/webrtc/modules/audio_codi...
File webrtc/modules/audio_coding/audio_network_adaptor/frame_length_controller.h
(right):

https://codereview.webrtc.org/2429503002/diff/80001/webrtc/modules/audio_codi...
webrtc/modules/audio_coding/audio_network_adaptor/frame_length_controller.h:76:
std::vector<int>::const_iterator frame_length_ms_;
On 2016/10/19 09:12:01, kwiberg-webrtc wrote:
> Wait, what vector does this iterator point into?

to config_.encoder_frame_lengths_ms

https://codereview.webrtc.org/2429503002/diff/80001/webrtc/modules/audio_codi...
File webrtc/modules/audio_coding/codecs/opus/audio_encoder_opus.cc (right):

https://codereview.webrtc.org/2429503002/diff/80001/webrtc/modules/audio_codi...
webrtc/modules/audio_coding/codecs/opus/audio_encoder_opus.cc:310:
kSupportedFrameLengths + arraysize(kSupportedFrameLengths),
On 2016/10/19 09:12:01, kwiberg-webrtc wrote:
> You should be able to use std::begin(kSupportedFrameLengths) and
> std::end(kSupportedFrameLengths).

nice! thanks!

https://codereview.webrtc.org/2429503002/diff/80001/webrtc/modules/audio_codi...
File webrtc/modules/audio_coding/codecs/opus/audio_encoder_opus.h (right):

https://codereview.webrtc.org/2429503002/diff/80001/webrtc/modules/audio_codi...
webrtc/modules/audio_coding/codecs/opus/audio_encoder_opus.h:106: const
std::vector<int>& supported_frame_lengths_ms() const {
On 2016/10/19 09:12:01, kwiberg-webrtc wrote:
> Again, I wonder if the return type here shouldn't be rtc::ArrayView<const
int>.

if config_.supported_frame_lengths_ms is a vector, it is any benefit of
returning rtc::ArrayView<const int>

[kwiberg-webrtc, 2016-10-19 10:43:33]

https://codereview.webrtc.org/2429503002/diff/80001/webrtc/modules/audio_codi...
File webrtc/modules/audio_coding/audio_network_adaptor/controller_manager.cc
(right):

https://codereview.webrtc.org/2429503002/diff/80001/webrtc/modules/audio_codi...
webrtc/modules/audio_coding/audio_network_adaptor/controller_manager.cc:145:
const std::vector<int>& encoder_frame_lengths_ms,
On 2016/10/19 09:25:54, minyue-webrtc wrote:
> On 2016/10/19 09:12:01, kwiberg-webrtc wrote:
> > Why did you make this change?
> 
> Because it is easier to construct a vector at the current caller.

Well, marginally---given an ArrayView av, you should be able to create a vector
like this:

  std::vector<int> v(av.cbegin(), av.cend());

The advantage of using ArrayView instead of const vector& for the function
argument is that you don't force the caller to hold the data in a vector. It can
be a vector, but also e.g. an array, or anything else that stores the elements
contiguously in memory.

https://codereview.webrtc.org/2429503002/diff/80001/webrtc/modules/audio_codi...
File webrtc/modules/audio_coding/audio_network_adaptor/frame_length_controller.h
(right):

https://codereview.webrtc.org/2429503002/diff/80001/webrtc/modules/audio_codi...
webrtc/modules/audio_coding/audio_network_adaptor/frame_length_controller.h:76:
std::vector<int>::const_iterator frame_length_ms_;
On 2016/10/19 09:25:54, minyue-webrtc wrote:
> On 2016/10/19 09:12:01, kwiberg-webrtc wrote:
> > Wait, what vector does this iterator point into?
> 
> to config_.encoder_frame_lengths_ms

OK, good, I was afraid that it might be pointing to the original vector passed
in by the caller (which would be bad because that one need not stay alive long
enough). Thanks.

https://codereview.webrtc.org/2429503002/diff/80001/webrtc/modules/audio_codi...
File webrtc/modules/audio_coding/codecs/opus/audio_encoder_opus.h (right):

https://codereview.webrtc.org/2429503002/diff/80001/webrtc/modules/audio_codi...
webrtc/modules/audio_coding/codecs/opus/audio_encoder_opus.h:106: const
std::vector<int>& supported_frame_lengths_ms() const {
On 2016/10/19 09:25:54, minyue-webrtc wrote:
> On 2016/10/19 09:12:01, kwiberg-webrtc wrote:
> > Again, I wonder if the return type here shouldn't be rtc::ArrayView<const
> int>.
> 
> if config_.supported_frame_lengths_ms is a vector, it is any benefit of
> returning rtc::ArrayView<const int>

No, but there are also no disadvantages. And the API then makes it possible for
you to change how you store the supported frame lengths.

Basically, everywhere where you pass an array of contiguous elements as a
function argument or return value, and the recipient is only allowed to access
the elements and not do anything to the length or ownership of the array,
rtc::ArrayView is just as good as std::vector&, rtc::Buffer&, etc., but places
fewer restrictions on how that memory is managed.

[minyue-webrtc, 2016-10-21 08:26:29]

Hi Karl,

Thanks for the comments! Now is a new patch set.

https://codereview.chromium.org/2429503002/diff/80001/webrtc/modules/audio_co...
File webrtc/modules/audio_coding/audio_network_adaptor/controller_manager.cc
(right):

https://codereview.chromium.org/2429503002/diff/80001/webrtc/modules/audio_co...
webrtc/modules/audio_coding/audio_network_adaptor/controller_manager.cc:145:
const std::vector<int>& encoder_frame_lengths_ms,
On 2016/10/19 10:43:33, kwiberg-webrtc wrote:
> On 2016/10/19 09:25:54, minyue-webrtc wrote:
> > On 2016/10/19 09:12:01, kwiberg-webrtc wrote:
> > > Why did you make this change?
> > 
> > Because it is easier to construct a vector at the current caller.
> 
> Well, marginally---given an ArrayView av, you should be able to create a
vector
> like this:
> 
>   std::vector<int> v(av.cbegin(), av.cend());
> 
> The advantage of using ArrayView instead of const vector& for the function
> argument is that you don't force the caller to hold the data in a vector. It
can
> be a vector, but also e.g. an array, or anything else that stores the elements
> contiguously in memory.

Ok. thanks, yes. I'd changed it back.

https://codereview.chromium.org/2429503002/diff/80001/webrtc/modules/audio_co...
File webrtc/modules/audio_coding/codecs/opus/audio_encoder_opus.h (right):

https://codereview.chromium.org/2429503002/diff/80001/webrtc/modules/audio_co...
webrtc/modules/audio_coding/codecs/opus/audio_encoder_opus.h:106: const
std::vector<int>& supported_frame_lengths_ms() const {
On 2016/10/19 10:43:33, kwiberg-webrtc wrote:
> On 2016/10/19 09:25:54, minyue-webrtc wrote:
> > On 2016/10/19 09:12:01, kwiberg-webrtc wrote:
> > > Again, I wonder if the return type here shouldn't be rtc::ArrayView<const
> > int>.
> > 
> > if config_.supported_frame_lengths_ms is a vector, it is any benefit of
> > returning rtc::ArrayView<const int>
> 
> No, but there are also no disadvantages. And the API then makes it possible
for
> you to change how you store the supported frame lengths.
> 
> Basically, everywhere where you pass an array of contiguous elements as a
> function argument or return value, and the recipient is only allowed to access
> the elements and not do anything to the length or ownership of the array,
> rtc::ArrayView is just as good as std::vector&, rtc::Buffer&, etc., but places
> fewer restrictions on how that memory is managed.

ok, yes, changed to rtc::ArrayView. Thanks for the explanation, This will also
help in my future CLs.

[kwiberg-webrtc, 2016-10-21 08:56:15]

lgtm

[michaelt, 2016-10-21 09:31:20]

lgtm

[minyue-webrtc, 2016-10-21 09:34:40]

The CQ bit was checked by minyue@webrtc.org

[commit-bot: I haz the power, 2016-10-21 09:34:43]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...

[commit-bot: I haz the power, 2016-10-21 09:44:52]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-21 09:44:54]

Try jobs failed on following builders:
  mac_rel on master.tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/mac_rel/builds/19351)

[minyue-webrtc, 2016-10-21 20:46:07]

Hi Karl,

Please take a look at my solution in checking ArrayView in unitttest and advise.

[minyue-webrtc, 2016-10-21 20:46:14]

The CQ bit was checked by minyue@webrtc.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-21 20:46:19]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...

[commit-bot: I haz the power, 2016-10-21 22:46:53]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-21 22:46:54]

Dry run: Try jobs failed on following builders:
  android_arm64_rel on master.tryserver.webrtc (JOB_TIMED_OUT, no build URL)
  android_clang_dbg on master.tryserver.webrtc (JOB_TIMED_OUT, no build URL)
  android_compile_mips_dbg on master.tryserver.webrtc (JOB_TIMED_OUT, no build
URL)
  android_compile_x64_dbg on master.tryserver.webrtc (JOB_TIMED_OUT, no build
URL)
  android_compile_x86_dbg on master.tryserver.webrtc (JOB_TIMED_OUT, no build
URL)
  android_compile_x86_rel on master.tryserver.webrtc (JOB_TIMED_OUT, no build
URL)
  android_dbg on master.tryserver.webrtc (JOB_TIMED_OUT, no build URL)
  android_gyp_dbg on master.tryserver.webrtc (JOB_TIMED_OUT, no build URL)
  android_rel on master.tryserver.webrtc (JOB_TIMED_OUT, no build URL)
  linux_arm on master.tryserver.webrtc (JOB_TIMED_OUT, no build URL)
  linux_asan on master.tryserver.webrtc (JOB_TIMED_OUT, no build URL)
  linux_compile_dbg on master.tryserver.webrtc (JOB_TIMED_OUT, no build URL)
  linux_gyp_dbg on master.tryserver.webrtc (JOB_TIMED_OUT, no build URL)
  linux_libfuzzer_rel on master.tryserver.webrtc (JOB_TIMED_OUT, no build URL)
  linux_msan on master.tryserver.webrtc (JOB_TIMED_OUT, no build URL)
  linux_rel on master.tryserver.webrtc (JOB_TIMED_OUT, no build URL)
  linux_tsan2 on master.tryserver.webrtc (JOB_TIMED_OUT, no build URL)
  linux_ubsan on master.tryserver.webrtc (JOB_TIMED_OUT, no build URL)
  linux_ubsan_vptr on master.tryserver.webrtc (JOB_TIMED_OUT, no build URL)
  presubmit on master.tryserver.webrtc (JOB_TIMED_OUT, no build URL)

[kwiberg-webrtc, 2016-10-24 11:58:35]

I think you should eliminate CheckArrayView and just call EXPECT_THAT directly.

https://codereview.chromium.org/2429503002/diff/120001/webrtc/modules/audio_c...
File webrtc/modules/audio_coding/codecs/opus/audio_encoder_opus_unittest.cc
(right):

https://codereview.chromium.org/2429503002/diff/120001/webrtc/modules/audio_c...
webrtc/modules/audio_coding/codecs/opus/audio_encoder_opus_unittest.cc:229:
const rtc::ArrayView<const int>& array_view) {
Pass ArrayView by value.

https://codereview.chromium.org/2429503002/diff/120001/webrtc/modules/audio_c...
webrtc/modules/audio_coding/codecs/opus/audio_encoder_opus_unittest.cc:231:
array_view.size()));
The actual value should be the first argument, and the matcher the second
argument:
https://github.com/google/googletest/blob/master/googlemock/docs/CheatSheet.m...

So

  EXPECT_THAT(array_view,
              ElementsAreArray(expected.data(), expected.size()));

https://codereview.chromium.org/2429503002/diff/120001/webrtc/modules/audio_c...
webrtc/modules/audio_coding/codecs/opus/audio_encoder_opus_unittest.cc:242:
states.encoder->supported_frame_lengths_ms());
I don't think you need the separate function:

EXPECT_THAT(states.encoder->supported_frame_lengths_ms(),
            ElementsAre(states.encoder->next_frame_length_ms()));

https://codereview.chromium.org/2429503002/diff/120001/webrtc/modules/audio_c...
webrtc/modules/audio_coding/codecs/opus/audio_encoder_opus_unittest.cc:244:
CheckArrayView({20, 60}, states.encoder->supported_frame_lengths_ms());
EXPECT_THAT(states.encoder->supported_frame_lengths_ms(),
            ElementsAre(20, 60));

[minyue-webrtc, 2016-10-24 12:52:05]

Thanks to Karl. Now have a nicer solution.

[kwiberg-webrtc, 2016-10-24 12:54:35]

lgtm

[minyue-webrtc, 2016-10-24 13:11:24]

The CQ bit was checked by minyue@webrtc.org

[minyue-webrtc, 2016-10-24 13:11:25]

The patchset sent to the CQ was uploaded after l-g-t-m from michaelt@webrtc.org
Link to the patchset: https://codereview.chromium.org/2429503002/#ps140001
(title: "nicer solution")

[commit-bot: I haz the power, 2016-10-24 13:11:31]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...

[commit-bot: I haz the power, 2016-10-24 15:12:06]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-24 15:12:08]

Try jobs failed on following builders:
  android_arm64_rel on master.tryserver.webrtc (JOB_TIMED_OUT, no build URL)
  android_clang_dbg on master.tryserver.webrtc (JOB_TIMED_OUT, no build URL)
  android_compile_mips_dbg on master.tryserver.webrtc (JOB_TIMED_OUT, no build
URL)
  android_compile_x64_dbg on master.tryserver.webrtc (JOB_TIMED_OUT, no build
URL)
  android_compile_x86_dbg on master.tryserver.webrtc (JOB_TIMED_OUT, no build
URL)
  android_compile_x86_rel on master.tryserver.webrtc (JOB_TIMED_OUT, no build
URL)
  android_dbg on master.tryserver.webrtc (JOB_TIMED_OUT, no build URL)
  android_gyp_dbg on master.tryserver.webrtc (JOB_TIMED_OUT, no build URL)
  android_rel on master.tryserver.webrtc (JOB_TIMED_OUT, no build URL)
  linux_arm on master.tryserver.webrtc (JOB_TIMED_OUT, no build URL)
  linux_asan on master.tryserver.webrtc (JOB_TIMED_OUT, no build URL)
  linux_compile_dbg on master.tryserver.webrtc (JOB_TIMED_OUT, no build URL)
  linux_gyp_dbg on master.tryserver.webrtc (JOB_TIMED_OUT, no build URL)
  linux_libfuzzer_rel on master.tryserver.webrtc (JOB_TIMED_OUT, no build URL)
  linux_msan on master.tryserver.webrtc (JOB_TIMED_OUT, no build URL)
  linux_rel on master.tryserver.webrtc (JOB_TIMED_OUT, no build URL)
  linux_tsan2 on master.tryserver.webrtc (JOB_TIMED_OUT, no build URL)
  linux_ubsan on master.tryserver.webrtc (JOB_TIMED_OUT, no build URL)
  linux_ubsan_vptr on master.tryserver.webrtc (JOB_TIMED_OUT, no build URL)

[minyue-webrtc, 2016-10-24 15:54:46]

The CQ bit was checked by minyue@webrtc.org

[commit-bot: I haz the power, 2016-10-24 15:54:54]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...

[commit-bot: I haz the power, 2016-10-24 16:19:17]

Description was changed from

==========
Simplifying audio network adaptor by moving receiver frame length range to ctor.

It turns out that that audio network adaptor can always be created with
knowledge of receiver frame length range. There is no need to keep some
infrastructure that is used for runtime setting of receiver frame length ranges.

BUG=webrtc:6303
==========

to

==========
Simplifying audio network adaptor by moving receiver frame length range to ctor.

It turns out that that audio network adaptor can always be created with
knowledge of receiver frame length range. There is no need to keep some
infrastructure that is used for runtime setting of receiver frame length ranges.

BUG=webrtc:6303
==========

[commit-bot: I haz the power, 2016-10-24 16:19:18]

Committed patchset #5 (id:140001)

[commit-bot: I haz the power, 2016-10-24 16:19:30]

Description was changed from

==========
Simplifying audio network adaptor by moving receiver frame length range to ctor.

It turns out that that audio network adaptor can always be created with
knowledge of receiver frame length range. There is no need to keep some
infrastructure that is used for runtime setting of receiver frame length ranges.

BUG=webrtc:6303
==========

to

==========
Simplifying audio network adaptor by moving receiver frame length range to ctor.

It turns out that that audio network adaptor can always be created with
knowledge of receiver frame length range. There is no need to keep some
infrastructure that is used for runtime setting of receiver frame length ranges.

BUG=webrtc:6303

Committed: https://crrev.com/a6f495c7c20e8b5ae33766ebbb1265ba14389e5a
Cr-Commit-Position: refs/heads/master@{#14748}
==========

[commit-bot: I haz the power, 2016-10-24 16:19:31]

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