Switch AudioRenderSink::Callback to use AudioBus.

media/base/audio_renderer_sink.h

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef MEDIA_BASE_AUDIO_RENDERER_SINK_H_
 #define MEDIA_BASE_AUDIO_RENDERER_SINK_H_
 
 #include <vector>
 #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 {
 
 // AudioRendererSink is an interface representing the end-point for
 // rendered audio.  An implementation is expected to
 // periodically call Render() on a callback object.
 
 class AudioRendererSink
     : public base::RefCountedThreadSafe<media::AudioRendererSink> {
  public:
   class RenderCallback {
    public:
     // Fills entire buffer of length |number_of_frames| but returns actual
     // number of frames it got from its source (|number_of_frames| in case of
     // 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;
 
     // Signals an error has occurred.
     virtual void OnRenderError() = 0;
 
    protected:
     virtual ~RenderCallback() {}
   };
 
   // Sets important information about the audio stream format.
@@ skipping 18 matching lines @@
   virtual bool SetVolume(double volume) = 0;
 
  protected:
   friend class base::RefCountedThreadSafe<AudioRendererSink>;
   virtual ~AudioRendererSink() {}
 };
 
 }  // namespace media
 
 #endif  // MEDIA_BASE_AUDIO_RENDERER_SINK_H_