Very early implementation for HTMLMediaElement / Web Audio API integration

content/renderer/media/audio_device.h

Index: content/renderer/media/audio_device.h
===================================================================
--- content/renderer/media/audio_device.h	(revision 96995)
+++ content/renderer/media/audio_device.h	(working copy)
@@ -57,10 +57,8 @@
 
 struct AudioParameters;
 
-class AudioDevice
-    : public AudioMessageFilter::Delegate,
-      public base::DelegateSimpleThread::Delegate,
-      public base::RefCountedThreadSafe<AudioDevice> {
+
+class AudioSink : public base::RefCountedThreadSafe<AudioSink> {

[scherkus (not reviewing), 2011/08/23 15:16:01]

what's the reasoning behind using an AudioSink as opposed to passing an
AudioDevice directly?

should also get moved to a separate .h file w/ docs

[Chris Rogers, 2011/08/24 00:41:52]

The idea is that there can be more than one kind of AudioSink:
1) AudioDevice which talks to the browser process
2) RenderAudioSourceProvider which connects into MediaElementAudioSourceNode
inside WebKit
3) ... maybe some other kind of destination for rendered audio stream in the
renderer ...

In this latest patch, I've renamed AudioSink to AudioRendererSink

On 2011/08/23 15:16:01, scherkus wrote:

  public:
   class RenderCallback {
    public:
@@ -71,6 +69,24 @@
     virtual ~RenderCallback() {}
   };
 
+  // Starts audio playback. Returns |true| on success.
+  virtual bool Start() = 0;
+
+    // Stops audio playback. Returns |true| on success.
+  virtual bool Stop() = 0;
+
+  // Sets the playback volume, with range [0.0, 1.0] inclusive.
+  // Returns |true| on success.
+  virtual bool SetVolume(double volume) = 0;
+};
+
+
+class AudioDevice
+    : public AudioMessageFilter::Delegate,
+      public base::DelegateSimpleThread::Delegate,
+      public AudioSink {
+ public:
+
   // Methods called on main render thread -------------------------------------
   AudioDevice(size_t buffer_size,
               int channels,