Audio output debug recording.

media/audio/audio_io.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_AUDIO_AUDIO_IO_H_
 #define MEDIA_AUDIO_AUDIO_IO_H_
 
 #include <stdint.h>
 
+#include "base/files/file_path.h"
 #include "base/time/time.h"
 #include "media/base/audio_bus.h"
 
 // Low-level audio output support. To make sound there are 3 objects involved:
 // - AudioSource : produces audio samples on a pull model. Implements
 //   the AudioSourceCallback interface.
 // - AudioOutputStream : uses the AudioSource to render audio on a given
 //   channel, format and sample frequency configuration. Data from the
 //   AudioSource is delivered in a 'pull' model.
 // - AudioManager : factory for the AudioOutputStream objects, manager
@@ skipping 79 matching lines @@
   // the callback object that was supplied to Start() and it can be safely
   // deleted.
   virtual void Stop() = 0;
 
   // Sets the relative volume, with range [0.0, 1.0] inclusive.
   virtual void SetVolume(double volume) = 0;
 
   // 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;
 };
 
 // Models an audio sink receiving recorded audio from the audio driver.
 class MEDIA_EXPORT AudioInputStream {
  public:
   class MEDIA_EXPORT AudioInputCallback {
    public:
@@ skipping 58 matching lines @@
   // Returns the Automatic Gain Control (AGC) state.
   virtual bool GetAutomaticGainControl() = 0;
 
   // Returns the current muting state for the microphone.
   virtual bool IsMuted() = 0;
 };
 
 }  // namespace media
 
 #endif  // MEDIA_AUDIO_AUDIO_IO_H_