Fix initial buffer sizes and improve partial underflow support.

media/renderers/audio_renderer_impl.cc

Index: media/renderers/audio_renderer_impl.cc
diff --git a/media/renderers/audio_renderer_impl.cc b/media/renderers/audio_renderer_impl.cc
index 3d24cf6508bc8a10518b0d60f94b4658755d7579..c653bfccbdcbe95ac2c3ba0a522a46b9ec607e66 100644
--- a/media/renderers/audio_renderer_impl.cc
+++ b/media/renderers/audio_renderer_impl.cc
@@ -348,14 +348,17 @@ void AudioRendererImpl::Initialize(DemuxerStream* stream,
   if (!expecting_config_changes_ || !hw_params.IsValid() ||
       hw_params.format() == AudioParameters::AUDIO_FAKE) {
     // The actual buffer size is controlled via the size of the AudioBus
-    // provided to Render(), so just choose something reasonable here for looks.
-    int buffer_size = stream->audio_decoder_config().samples_per_second() / 100;
-    audio_parameters_.Reset(
-        AudioParameters::AUDIO_PCM_LOW_LATENCY,
-        stream->audio_decoder_config().channel_layout(),
-        stream->audio_decoder_config().samples_per_second(),
-        stream->audio_decoder_config().bits_per_channel(),
-        buffer_size);
+    // provided to Render(), but we should choose a value here based on hardware
+    // parameters if possible since it affects the initial buffer size used by
+    // the algorithm. Too little will cause underflow on Bluetooth devices.
+    int buffer_size =
+        std::max(stream->audio_decoder_config().samples_per_second() / 100,
+                 hw_params.IsValid() ? hw_params.frames_per_buffer() : 0);
+    audio_parameters_.Reset(AudioParameters::AUDIO_PCM_LOW_LATENCY,
+                            stream->audio_decoder_config().channel_layout(),
+                            stream->audio_decoder_config().samples_per_second(),
+                            stream->audio_decoder_config().bits_per_channel(),
+                            buffer_size);
     buffer_converter_.reset();
   } else {
     // To allow for seamless sample rate adaptations (i.e. changes from say
@@ -851,6 +854,10 @@ int AudioRendererImpl::Render(AudioBus* audio_bus,
         algorithm_->IncreaseQueueCapacity();
         SetBufferingState_Locked(BUFFERING_HAVE_NOTHING);
       }
+    } else if (frames_written < frames_requested && !received_end_of_stream_) {
+      // If we only partially filled the request and should have more data, go

[chcunningham, 2016/09/28 19:59:30]

When do we expect this to be triggered? Given your change above to the initial
buffer size, I'm not sure if this is actually used?

Could this end up being triggered when we're just underflowing? I.e. we wrote >
0 frames but less than requested, not because our queue size was too small, but
just because decoding is too slow or not enough audio has downloaded. 

I think you can solve that second concern by checking the current queue capacity
against the size of frames_requested -- if its already pretty big then don't
increase.

[DaleCurtis, 2016/09/28 21:43:28]

The other change fixes the known cases, but buffer sizes are flexible in the
renderer. If a device change happens, we may end up on a device which needs a
larger buffer size. Without this, we can't adapt in the event of partial fills.

I expect it to be triggered slightly before we underflow now; potentially
avoiding an actual pause-for-underflow event. What's your concern with this
piece of code?

+      // ahead and increase queue capacity to try and meet the next request.
+      algorithm_->IncreaseQueueCapacity();
     }
 
     audio_clock_->WroteAudio(frames_written + frames_after_end_of_stream,