Drop 48kHz sample rate support in the APM for ARM architecture

webrtc/modules/audio_processing/audio_processing_impl.cc

Index: webrtc/modules/audio_processing/audio_processing_impl.cc
diff --git a/webrtc/modules/audio_processing/audio_processing_impl.cc b/webrtc/modules/audio_processing/audio_processing_impl.cc
index dbc04b7cf34f5fedf29b613139ba93a5b8c281fe..2eed2ebc2e7a411b8bace3c265ff1bd155de4931 100644
--- a/webrtc/modules/audio_processing/audio_processing_impl.cc
+++ b/webrtc/modules/audio_processing/audio_processing_impl.cc
@@ -112,8 +112,12 @@ struct AudioProcessingImpl::ApmPrivateSubmodules {
 const int AudioProcessing::kNativeSampleRatesHz[] = {
     AudioProcessing::kSampleRate8kHz,
     AudioProcessing::kSampleRate16kHz,
+#ifdef WEBRTC_ARCH_ARM_FAMILY
+    AudioProcessing::kSampleRate32kHz};

[peah-webrtc, 2016/03/05 10:56:41]

What is the impact of this on current platforms? What happens if APM is actually
being opened in 48 kHz on ARM? I guess that there is an error message?

We need to make sure that 
1) Make sure that this change does not break WebRTC for any currently running
ARM platforms.
2) The error message that is caused by this is properly addressed when received
by a caller of APM.

The next question is what to do instead. On Android, I'm quite sure that we are
called with 48 kHz when AECM is not active. Should we then downsample to 32 kHz
internally?

[aluebs-webrtc, 2016/03/07 11:32:15]

What do you mean by "being opened"? If the APM receives a signal of 48kHz it
would just downsample to 32kHz at the input and upsample it again at the end. So
there is no error message.

[peah-webrtc, 2016/03/07 12:50:48]

I think I see it now. So this change has nothing to do with supported sample
rates, right? The kNativeSampleRatesHz array is only used to determine the
minimum processing rate, right? And has nothing to do with the supported sample
rates, right?

Then this change should be fine as you say.

So what then instead happens is that the 3-bandsplitting is replaced by an
down+upsampling? Which should be cheaper than the 3-bandsplitting, right?

[peah-webrtc, 2016/03/07 12:50:48]

I have another question about this code. Currently it is only used as to set the
processing rate as:

const int AudioProcessing::kNativeSampleRatesHz[] = {
    AudioProcessing::kSampleRate8kHz,
    AudioProcessing::kSampleRate16kHz,
    AudioProcessing::kSampleRate32kHz,
    AudioProcessing::kSampleRate48kHz};
const size_t AudioProcessing::kNumNativeSampleRates =
    arraysize(AudioProcessing::kNativeSampleRatesHz);
const int AudioProcessing::kMaxNativeSampleRateHz = AudioProcessing::
    kNativeSampleRatesHz[AudioProcessing::kNumNativeSampleRates - 1];

...

int fwd_proc_rate;
  for (size_t i = 0; i < kNumNativeSampleRates; ++i) {
    fwd_proc_rate = kNativeSampleRatesHz[i];
    if (fwd_proc_rate >= min_proc_rate) {
      break;
    }
  }


Why not change that to (the example excluding your changes in this CL)
const int AudioProcessing::kMaxNativeSampleRateHz =
AudioProcessing::kSampleRate48kHz;
...
const int fwd_proc_rate = AudioProcessing::kMaxNativeSampleRateHz;

[aluebs-webrtc, 2016/03/07 13:02:01]

As you say, this would replace the 3-band splitting by a down- and up-sampling.
Regarding your suggestion, this would force to use 48kHz always, which is not
what we want to do if we get and input (or output) sample rate of, let's say,
16kHz.

[peah-webrtc, 2016/03/10 07:01:00]

Ah, then I see. Then the change is fine.

+#else
     AudioProcessing::kSampleRate32kHz,
     AudioProcessing::kSampleRate48kHz};
+#endif  // WEBRTC_ARCH_ARM_FAMILY
 const size_t AudioProcessing::kNumNativeSampleRates =
     arraysize(AudioProcessing::kNativeSampleRatesHz);
 const int AudioProcessing::kMaxNativeSampleRateHz = AudioProcessing::