Audio output debug recording.

media/audio/audio_io.h

Index: media/audio/audio_io.h
diff --git a/media/audio/audio_io.h b/media/audio/audio_io.h
index 6ab50aa952e88e5ca97c3d903d40da530d59e104..060f2f6ec5c446e76455b07a9672865025bcfa5c 100644
--- a/media/audio/audio_io.h
+++ b/media/audio/audio_io.h
@@ -7,6 +7,7 @@
 
 #include <stdint.h>
 
+#include "base/files/file_path.h"
 #include "base/time/time.h"
 #include "media/base/audio_bus.h"
 
@@ -106,6 +107,12 @@ class MEDIA_EXPORT AudioOutputStream {
   // Gets the relative volume, with range [0.0, 1.0] inclusive.
   virtual void GetVolume(double* volume) = 0;
 
+  // Enable debug recording. A file type extension is added to |file_name|.

[DaleCurtis, 2017/01/19 17:44:34]

Hmm this is an API only AudioManager should use, so I don't think it belongs on
this interface. Instead we might want a new AudioDebugRecording interface that
output streams also implement. Or some way to avoid this API at all. Potentially
by using the AudioOutputResampler to trigger this recording instead (it
intercepts the audio data).

[Henrik Grunell, 2017/01/19 20:32:39]

How could AudioOutputResampler do this without an API? I guess I'm not familiar
with the interception mechanism and how that can be used. Also, the AOR isn't
always used, right? An AudioOutputDispatcherImpl could be used directly afaik.

[DaleCurtis, 2017/01/19 22:37:29]

AODI is only used for fake streams these days, so it would miss some. AM also
uses AOR directly, so no interface API is needed, just some direct methods on
AOR.

[Henrik Grunell, 2017/01/20 10:38:56]

Oh, I think you mean that recording is done in AOR. (I was thinking AOR somehow
would inform the stream.) That's an option of course. The reason I want to do it
in the stream is to have bisect point as close to the Chrome border as possible.
There's for example re-buffering on Mac in the stream implementation. I'd really
like the recording point to be after that and the other code in the stream
implementations.

Have streams implement another interface sgtm. I'm thinking that those who
implement it could call back to AM to register themselves.

I could accept doing it AOR; one benefit is obviously a single place for the
recording, and it would still give us valuable information.

[DaleCurtis, 2017/01/20 17:52:20]

Yeah, stuff like the rebuffering in OSX wouldn't be caught, but otherwise AOR is
the last line before streams, and generally the per-stream stuff should be
minor. I think between AOR and the output stream you're very unlikely to get
useful information.

+  virtual void EnableDebugRecording(const base::FilePath& file_name) = 0;
+
+  // Disable debug recording.
+  virtual void DisableDebugRecording() = 0;
+
   // Close the stream. This also generates AudioSourceCallback::OnClose().
   // After calling this method, the object should not be used anymore.
   virtual void Close() = 0;