Classify ARM Chromebooks as high latency audio.

ppapi/shared_impl/ppb_audio_config_shared.cc

Index: ppapi/shared_impl/ppb_audio_config_shared.cc
===================================================================
--- ppapi/shared_impl/ppb_audio_config_shared.cc	(revision 221928)
+++ ppapi/shared_impl/ppb_audio_config_shared.cc	(working copy)
@@ -2,6 +2,7 @@
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
+#include "build/build_config.h"
 #include "ppapi/shared_impl/ppb_audio_config_shared.h"
 #include "ppapi/thunk/enter.h"
 #include "ppapi/thunk/ppb_instance_api.h"
@@ -81,6 +82,16 @@
   // care when modifying these values as they impact a large number of users.
   // TODO(dalecurtis): Land jitter test and add documentation for updating this.
 
+  // Should track the value reported by XP and ALSA backends.
+  const uint32_t kHighLatencySampleFrameCount = 2048;
+
+#if defined(OS_CHROMEOS) && defined(ARCH_CPU_ARM_FAMILY)
+  // TODO(ihf): Remove this once ARM Chromebooks support low latency audio. For
+  // now we classify them as high latency. See crbug.com/289770.

[dmichael (off chromium), 2013/09/13 20:44:46]

This doesn't seem like the right place to fix this. Pepper shouldn't need to
know much about specific hardware; that should usually be shared. What about
AudioHardwareConfig?:
https://code.google.com/p/chromium/codesearch#chromium/src/media/base/audio_h...

+  return CalculateMultipleOfSampleFrameCount(
+      sample_frame_count, kHighLatencySampleFrameCount);

[dmichael (off chromium), 2013/09/13 21:15:56]

should we copy the high latency section below and use:
std::max(kHighLatencySampleFrameCount, hardware_sample_frame_count);
?

Or add another way in to that "if" condition, so we don't need this separate
call? E.g.:
#if defined(OS_CHROMEOS) && defined(ARCH_CPU_ARM_FAMILY)
const bool kHighLatencyDevice = true;
#else
const bool kHighLatencyDevice = true;
#endif

and edit 106 to say
if (kHighLatencyDevice ||
    //... etc ...

Also, it would be nice to comment on why we do this platform checking here
instead of at a lower level.

[ilja, 2013/09/14 01:44:39]

I followed the second approach and left a comment.

+#endif  // defined(OS_CHROMEOS) && defined(ARCH_CPU_ARM_FAMILY)
+
   // If client is using same sample rate as audio hardware, then recommend a
   // multiple of the audio hardware's sample frame count.
   if (hardware_sample_rate == sample_rate) {
@@ -88,9 +99,6 @@
         hardware_sample_frame_count, sample_frame_count);
   }
 
-  // Should track the value reported by XP and ALSA backends.
-  const uint32_t kHighLatencySampleFrameCount = 2048;
-
   // If the hardware requires a high latency buffer or we're at a low sample
   // rate w/ a buffer that's larger than 10ms, choose the nearest multiple of
   // the high latency sample frame count.  An example of too low and too large