Caching AudioOutputDevice instances in mixer manager

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 5853864bf278f19e39e9f5242d7bea761316da52..c7e63e07d7d58d301bebf04faf5edb173bce3005 100644
--- a/media/renderers/audio_renderer_impl.cc
+++ b/media/renderers/audio_renderer_impl.cc
@@ -36,14 +36,12 @@ AudioRendererImpl::AudioRendererImpl(
     const scoped_refptr<base::SingleThreadTaskRunner>& task_runner,
     media::AudioRendererSink* sink,
     ScopedVector<AudioDecoder> decoders,
-    const AudioHardwareConfig& hardware_config,
     const scoped_refptr<MediaLog>& media_log)
     : task_runner_(task_runner),
       expecting_config_changes_(false),
       sink_(sink),
       audio_buffer_stream_(
           new AudioBufferStream(task_runner, std::move(decoders), media_log)),
-      hardware_config_(hardware_config),
       media_log_(media_log),
       client_(nullptr),
       tick_clock_(new base::DefaultTickClock()),
@@ -333,7 +331,8 @@ void AudioRendererImpl::Initialize(DemuxerStream* stream,
   // failed.
   init_cb_ = BindToCurrentLoop(init_cb);
 
-  const AudioParameters& hw_params = hardware_config_.GetOutputConfig();
+  const AudioParameters& hw_params =

[DaleCurtis, 2016/05/26 19:18:09]

Do you know what this returns when the element is attached to WebAudio? If it
returns invalid parameters, that's actually good since we'll try to output at
input parameters which is best for WebAudio.

[o1ka, 2016/05/27 13:48:52]

This is a good question.

Here
https://code.google.com/p/chromium/codesearch#chromium/src/media/blink/webaud...

it returns device info with OUTPUT_DEVICE_STATUS_ERROR_INTERNAL and
UnavailableDeviceParams(defined here
https://code.google.com/p/chromium/codesearch#chromium/src/media/base/audio_p...)
which are valid, but AUDIO_FAKE, so we do fail back to input parameters here.

But in fact I'm not sure if it's correct. As far as I understand,
WebAudioSourceProviderImpl client can be reset by HTMLMediaElement to nullptr
later, which means rendering will switch to the real sink (ARMI). But pipeline
will continue to output at input parameters, which is a new behavior, and I'm
not sure that it's desired.
So, in order to keep the things as they are, I modified
WebAudioSourceProviderImpl to always return actual sink parameters no matter if
the client is set or not.

I can change that in a follow-up CL if you confirm that the new behavior is
valid.

(Note that if WebAudioSourceProvider is initialized with NullAudioSink  we do
output on input params here, because NullAudioSink params are AUDIO_FAKE)

+      sink_->GetOutputDeviceInfo().output_params();
   expecting_config_changes_ = stream->SupportsConfigChanges();
   if (!expecting_config_changes_ || !hw_params.IsValid() ||
       hw_params.format() == AudioParameters::AUDIO_FAKE) {