Introduce AudioHardwareConfig for renderer side audio device info.

media/audio/audio_output_controller.cc

Index: media/audio/audio_output_controller.cc
diff --git a/media/audio/audio_output_controller.cc b/media/audio/audio_output_controller.cc
index e3464fd6fdf9acc5f11f56a6b5f20071279159fa..a4b827bd3a6ed8cb0392738ac1c02f2d459d948f 100644
--- a/media/audio/audio_output_controller.cc
+++ b/media/audio/audio_output_controller.cc
@@ -10,6 +10,7 @@
 #include "base/threading/platform_thread.h"
 #include "base/time.h"
 #include "build/build_config.h"
+#include "media/audio/audio_util.h"
 #include "media/audio/shared_memory_util.h"
 
 using base::Time;
@@ -328,6 +329,12 @@ void AudioOutputController::DoStopCloseAndClearStream() {
 void AudioOutputController::OnDeviceChange() {
   DCHECK(message_loop_->BelongsToCurrentThread());
 
+  // Notify the renderer side that a device change has occurred.
+  // TODO(dalecurtis): The new hardware information should be passed in, instead
+  // of being retrieved by every single AudioOutputController.
+  handler_->OnDeviceChange(

[miu, 2013/01/29 04:55:43]

Should this instead be:

  handler_->OnDeviceChange(
      this, params_.GetBytesPerBuffer(), params_.sample_rate());

I may be misunderstanding something, but here's what I see happening:

1. AudioOutputController::params_ is a constant.
2. When DoCreate() re-creates the stream, it will call
audio_manager_->MakeAudioOutputStreamProxy(params_);
3. AudioManager will use AudioOutputResampler and friends to handle mismatches
in what the hardware actually supports versus the params_ requested.

So, from the render process' point-of-view, it should keep supplying audio data
at the original sampling rate, buffer size, etc., right?

[DaleCurtis, 2013/01/29 19:36:00]

No, the purpose of this call is to update the renderer's cached hardware
configuration values.  In the future AudioRendererMixer will recreate based on
these values.

params_ is already known to the renderer, so issuing the call as you describe it
provides no information to the client.

[miu, 2013/01/29 22:04:34]

Okay, makes sense to me now.  And now the TODO comment makes more sense: I would
have expected AudioManager to push the device change notifications to each
render process.  However, with the media/content component boundaries, this
would be a lot of code.

[DaleCurtis, 2013/01/30 01:31:06]

Yeah, I suspect we need to plumb the values a la the TODO for Tab mirroring to
work.  Since it wants values which are not actually the hardware values.

+      this, GetAudioHardwareBufferSize(), GetAudioHardwareSampleRate());
+
   // Recreate the stream (DoCreate() will first shut down an existing stream).
   // Exit if we ran into an error.
   const State original_state = state_;