Switch AudioRenderSink::Callback to use AudioBus.

media/base/audio_renderer_sink.h

Index: media/base/audio_renderer_sink.h
diff --git a/media/base/audio_renderer_sink.h b/media/base/audio_renderer_sink.h
index 8786fe1826634c890643e386c57a83c934f53171..b0d2238244bf086be4dfb5df52c42abbbf5358f6 100644
--- a/media/base/audio_renderer_sink.h
+++ b/media/base/audio_renderer_sink.h
@@ -9,6 +9,7 @@
 #include "base/basictypes.h"
 #include "base/memory/ref_counted.h"
 #include "media/audio/audio_parameters.h"
+#include "media/base/audio_bus.h"
 #include "media/base/media_export.h"
 
 namespace media {
@@ -27,7 +28,7 @@ class AudioRendererSink
     // continuous stream). That actual number of frames is passed to host
     // together with PCM audio data and host is free to use or ignore it.
     // TODO(crogers): use base:Callback instead.
-    virtual int Render(const std::vector<float*>& audio_data,
+    virtual int Render(AudioBus* audio_bus,
                        int number_of_frames,

[DaleCurtis, 2012/08/07 23:12:19]

Do we need/want number_of_frames still? Or should Render() always fill the
AudioBus object completely.

Currently, SincResampler complicates making this change by requesting different
amounts of frames relative to the creation size of the AudioBus. If we fixed
that though, every caller is specifying AudioBus->frames() to Render().

[scherkus (not reviewing), 2012/08/07 23:23:41]

Doesn't seem too crazy -- what would the fix to SincResampler look like?
Creating/Wrapping AudioBuses?

[DaleCurtis, 2012/08/07 23:49:24]

There are few ways I can think of:
- Creating/wrapping AudioBus objects as you mention. E.g., create one, use
WrapVector() on the first one with different frame sizes. Has the bonus of
allowing one less memcpy per cycle like the existing implementation.
 - Recreate an AudioBus every ProvideInput call (what WebKit's
MultiChannelResampler does).
- Have AudioBus offer a SetFrames()/MaxFrames() method which allows downward
capping of AudioBus->frames(). Alternatively, a Resize() method which just caps
frames_ on downsizing/same-sizing and reallocates on upsizing.
- Fix SincResampler to always request the same amount of data (difficult I
think, maybe crogers would know better).

Buffering inside MCR is out since it would need to sync with some sort of 
flush() API.

[scherkus (not reviewing), 2012/08/08 00:49:01]

The first option sounds OK -- but we can tackle that in a future CL.

[DaleCurtis, 2012/08/08 01:26:07]

Actually it was pretty easy to do, so the next patch set has this change. Take a
look.

                        int audio_delay_milliseconds) = 0;