Add an initial revision of an audio server.

services/media/audio/audio_track_impl.h

+// 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 SERVICES_MEDIA_AUDIO_AUDIO_TRACK_IMPL_H_
+#define SERVICES_MEDIA_AUDIO_AUDIO_TRACK_IMPL_H_
+
+#include <deque>
+#include <set>
+
+#include "base/synchronization/lock.h"
+#include "mojo/public/cpp/bindings/binding.h"
+#include "mojo/public/cpp/bindings/callback.h"
+#include "mojo/services/media/audio/interfaces/audio_track.mojom.h"
+#include "mojo/services/media/common/cpp/linear_transform.h"
+#include "services/media/audio/audio_pipe.h"
+#include "services/media/audio/fwd_decls.h"
+#include "services/media/common/rate_control_base.h"
+
+namespace mojo {
+namespace media {
+namespace audio {
+
+class AudioTrackImpl : public AudioTrack {
+ public:
+  // TODO(johngro): Find a better place for this constant.  It affects the
+  // behavior of more than just the Audio Track implementation.
+  static constexpr size_t PTS_FRACTIONAL_BITS = 12;

[jeffbrown, 2015/11/04 23:43:33]

Maybe make a new fixed point datatype instead.

[johngro, 2015/11/06 02:20:26]

perhaps, but I would rather not at the moment.  I can make an entire templated
fixed point math library, but right now my use cases require nothing that
sophisticated.

I will put it on the list of things to consider doing eventually (esp. as the
team grows and we have more bandwidth) but right now I think we have much more
important things to do.

+
+  ~AudioTrackImpl() override;
+  static AudioTrackImplPtr Create(InterfaceRequest<AudioTrack> iface,
+                                 AudioServerImpl* owner);
+
+  // Implementation of AudioTrack interface.
+  void Describe(const DescribeCallback& cbk) override;

[jeffbrown, 2015/11/04 23:43:33]

These should be private.

[johngro, 2015/11/06 02:20:26]

Done.

+  void Configure(AudioTrackConfigurationPtr configuration,
+                 InterfaceRequest<MediaPipe> req,
+                 const ConfigureCallback& cbk) override;
+  void GetRateControl(InterfaceRequest<RateControl> req,
+                      const GetRateControlCallback& cbk) override;
+
+  // Methods used by the output manager to link this track to different outputs.
+  void AddOutput(AudioTrackToOutputLinkPtr link);
+  void RemoveOutput(AudioTrackToOutputLinkPtr link);
+
+  // Accessors used by AudioOutputs during mixing to access parameters which are
+  // important for the mixing process.
+  void SnapshotRateTrans(LinearTransform* out, uint32_t* generation = nullptr) {
+    rate_control_.SnapshotCurrentTransform(out, generation);
+  }
+
+  const LinearTransform::Ratio& FractionalFrameToMediaTimeRatio() const {
+    return frame_to_media_ratio_;
+  }
+
+  uint32_t BytesPerFrame() const { return bytes_per_frame_; }
+  const LpcmMediaTypeDetailsPtr& Format() const { return format_; }
+
+ private:
+  friend class AudioPipe;
+
+  AudioTrackImpl(InterfaceRequest<AudioTrack> track,
+                AudioServerImpl* owner);
+
+  void OnPacketReceived(AudioPipe::AudioPacketRefPtr packet);
+  void OnFlushRequested(const MediaPipe::FlushCallback& cbk);
+
+  AudioTrackImplWeakPtr      weak_this_;

[jeffbrown, 2015/11/04 23:43:33]

Using lots of typedefs makes it harder to understand the semantics of these
values without having to grep the header files.  Is this a WeakPtr?  I'm not
sure.  You might want to tone it down a bit before this turns into Hungarian
notation.

[johngro, 2015/11/06 02:20:26]

I'm not sure of exactly what you are concerned about here...  Is it the type
name or the member variable name?

Re; the type name...
I am attempting to follow the mojo style here.  They (frequently) generate
pointer types for their smart pointers to their interfaces and other objects. 
It follows the form MyObjectOrInterfacePtr.

Re: Is this a WeakPtr?
If you are asking about the type name, I had hoped that...
AudioTrackImpl**WeakPtr** had made it clear that this type was a weak pointer to
an AudioTrackImpl.

Re: typedefs.
The relationships between objects in this system mandates that many of the
objects hold various references and pointers to other objects in the system. 
Unless I wanted to end up in circular include file hell (is there a special
circle for that sin?), this requires many forward declarations, which is why I
centralized it all in the fwd_decls.h header.  I went ahead and defined types
for pointers and weak pointers and sets and the like because..
1) It seems to be the local mojo style.
2) The std pointer are collections are great!  Their syntax gets to be a little
gross (go ahead and type    std::set<std::shared_ptr<AudioTrackToOutputLink>,
std::owner_less<std::shared_ptr<AudioTrackToOutputLink>>>;
five times fast.)
3) Using typedefs help to enforce top level ownership design decisions.  Is this
supposed to be a unique_ptr or a shared_ptr?  The decision has already been made
for you, and is enforced for you.  In the unlikely case that we want to change
that decision, or switch from std::shared_ptr to mojo::even_better_shared_ptr,
we can do it in one place instead of all over the place.

Finally, re: weak_this_
This is an unfortunate side effect of the non-intrusive nature of shared/weak
pointers in the std:: library.  Sorry.

+  AudioServerImpl*          owner_;
+  Binding<AudioTrack>        binding_;

[jeffbrown, 2015/11/04 23:43:33]

alignment is a little wonky here

More importantly, I don't think git cl format will let you get away with this...

[johngro, 2015/11/06 02:20:26]

yeah, this happened because of the global rename from Sink to Track.  It has
been fixed.

+  AudioPipe                 pipe_;
+  RateControlBase           rate_control_;
+  LinearTransform::Ratio    frame_to_media_ratio_;
+  uint32_t                  bytes_per_frame_ = 1;
+  LpcmMediaTypeDetailsPtr   format_;
+  AudioTrackToOutputLinkSet outputs_;
+};
+
+}  // namespace audio
+}  // namespace media
+}  // namespace mojo
+
+#endif  // SERVICES_MEDIA_AUDIO_AUDIO_TRACK_IMPL_H_