Add an initial revision of an audio server.

services/media/audio/platform/generic/mixers/no_op.cc

+// 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.
+
+#include "base/logging.h"
+#include "services/media/audio/platform/generic/mixers/no_op.h"
+
+namespace mojo {
+namespace media {
+namespace audio {
+namespace mixers {
+
+bool NoOp::Mix(void*       dst,
+               uint32_t    dst_frames,
+               uint32_t*   dst_offset,
+               const void* src,
+               uint32_t    frac_src_frames,
+               uint32_t*   frac_src_offset,
+               uint32_t    frac_step_size,
+               bool        accumulate) {
+  DCHECK_LT(*dst_offset, dst_frames);
+  DCHECK_LT(*frac_src_offset, frac_src_frames);
+
+  uint32_t frames_produced = ((frac_src_frames - *frac_src_offset)
+                           + frac_step_size - 1) / frac_step_size;
+
+  if (frames_produced > (dst_frames - *dst_offset)) {
+      frames_produced = (dst_frames - *dst_offset);

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

The mixer functions themselves might be a little simpler if the caller did all
of this clamping for them.  After all, it should know whether an overflow will
happen.

Although I could see some argument for letting the mixer calculate it as it goes
since we'll probably determine these results while the mixer's loop executes too
(at least for a non-noop mixer).

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

I'm confused; there is no sample clamping going on here.  The goal (and what is
going on here) is to let the mixer/filter say how much of the input it has
consumed and how much of the output it has produced.  The reason for this is
that as we add more complicated temporal filters, the understanding of this
relationship really belong in the mixer class, and not in the outer loop.  The
outer loop should just keep giving the mixer more data until it has produced all
the sample it needs, or the mixer has decided that it has seen all of the input
it is interested in.

FWIW - I have some work in progress to allow filters of non-epsilon width, and
as part of that work, this NoOp Mix implementation actually disappears.

+  }
+
+  *dst_offset      += frames_produced;
+  *frac_src_offset += frames_produced * frac_step_size;
+
+  return (*frac_src_offset >= frac_src_frames);

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

I don't see why we need to return this value since it's something the caller
could determine directly.

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

See above; the caller needs to know details about the filter implemented by the
mixer to actually do that.  The filters implemented so far are trivial, but they
will not always be so.

+}
+
+}  // namespace mixers
+}  // namespace audio
+}  // namespace media
+}  // namespace mojo