Exposes a shlib interface for media/audio path.

chromecast/public/cast_audio_output_device.h

Index: chromecast/public/cast_audio_output_device.h
diff --git a/chromecast/public/cast_audio_output_device.h b/chromecast/public/cast_audio_output_device.h
new file mode 100644
index 0000000000000000000000000000000000000000..c6ba576c8ba79c54c2966a646117a167e9c8dbab
--- /dev/null
+++ b/chromecast/public/cast_audio_output_device.h
@@ -0,0 +1,44 @@
+// Copyright 2015 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 CHROMECAST_PUBLIC_CAST_AUDIO_OUTPUT_DEVICE_H_
+#define CHROMECAST_PUBLIC_CAST_AUDIO_OUTPUT_DEVICE_H_
+
+#include <string>

[halliwell, 2015/04/24 15:04:48]

Is <string> used?

[slan, 2015/04/24 16:19:39]

Nope. Artifact of re-factoring. Removed.

+
+#include "cast_audio_stream.h"
+#include "chromecast_export.h"
+
+namespace chromecast {
+
+// This is an interface used to provide platform-specific audio streams.
+// Implementations of this interface should survive for the duration of the
+// process.
+
+// Note: This interface should be implemented by third parties seeking to
+// provide an audio manager platform for Cast. CastAudioManager will call
+// this interface.
+

[halliwell, 2015/04/24 15:04:48]

How do implementations get instantiated ... is that a follow-up CL?

[slan, 2015/04/24 16:19:39]

Yes, follow-up CL. This merits a discussion about when the implementation is
injected. It needs to happen sometime before the main browser loop, but exactly
when and where is TBD.

I've opened a bug to track this: b/20551606

+class CHROMECAST_EXPORT CastAudioOutputDevice {
+ public:
+  virtual ~CastAudioOutputDevice() {}
+
+  // Returns the maximum number of output streams allowed.
+  virtual int GetMaximumOutputStreamsAllowed() const = 0;
+
+  // Returns the preferred output stream parameters. The caller may inject
+  // |suggested| parameters, but it is left to the implementation to decide
+  // which of these to return.
+  virtual AudioParameters GetPreferredOutputStreamParameters(
+      const AudioParameters& suggested) const = 0;
+
+  // Creates the output stream with parameters described by |params|. Caller
+  // does not take ownership of the returned stream.

[halliwell, 2015/04/24 15:04:48]

So what's the lifetime of these streams ... they live till process exits?

[slan, 2015/04/24 16:19:39]

Good question. For now, that is left up to the implementation of the stream and
the output device. Two assumptions which must hold:
 1) The pointer to the stream must remain valid until Close() is called or an
OnError() event is detected.
 2) The stream should not be freed, except by the output device, who owns it. 

Beyond that, it is left to implementer of the output device to decide when to
delete the stream (if at all).

However, I like the approach of the stream alerting the output device when it
has been Close()d. The output device (who owns the stream) then deletes the
stream. 

WDYT? Is this a robust approach?

[halliwell, 2015/04/25 01:34:10]

I'm not familiar with practical usage of these classes, so someone else should
comment, but it doesn't quite sound robust to me.  Considering that the
'OnClose' and 'OnError' callbacks are documented as happening on a random
thread, and if the stream will be deleted after them, it's not clear how the
client code can safely call methods on the stream and track its lifetime.  I
would have thought you either need some kind of threadsafe refcounting pointer
type for the client (could be weak), or you need some kind of stronger/clearer
threading model, e.g. if the notification that a stream is about to be deleted
comes on the same thread that it's used from, that would be safe.

+  virtual CastAudioOutputStream* MakeOutputStream(
+      const AudioParameters& params) = 0;
+};
+
+}  // namespace chromecast
+
+#endif  // CHROMECAST_PUBLIC_CAST_AUDIO_OUTPUT_DEVICE_H_