Adds media::AudioPullFifo class to Chrome.

media/base/audio_pull_fifo.cc

Index: media/base/audio_pull_fifo.cc
diff --git a/media/base/audio_pull_fifo.cc b/media/base/audio_pull_fifo.cc
new file mode 100644
index 0000000000000000000000000000000000000000..35f8e2ce6998229081e4bf48330ba47dc57adde6
--- /dev/null
+++ b/media/base/audio_pull_fifo.cc
@@ -0,0 +1,54 @@
+// 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.
+
+#include "media/base/audio_pull_fifo.h"
+
+#include "base/logging.h"
+
+namespace media {
+
+AudioPullFifo::AudioPullFifo(int channels, int frames,

[DaleCurtis, 2012/09/07 13:48:38]

Do we really need |read_frames|? It's kind of confusing to have |frames|,
|read_frames|, and |frames_to_consume|. I'd just use frames as read_frames or
vice versa.

[henrika (OOO until Aug 14), 2012/09/07 16:06:42]

Done.

+                             const ReadCB& read_cb, int read_frames)
+    : read_cb_(read_cb) {
+  DCHECK_LE(read_frames, frames);

[DaleCurtis, 2012/09/07 13:48:38]

I don't think you should make this assumption since PPAPI can request whatever
buffer size it wants. So far it's always greater than the hardware output size.
On Mac/Win it's unlikely they'd ever request a smaller buffer size (and expect
it to work), but on Linux it's possible they will choose something less than the
2k fixed buffer size we use.

[henrika (OOO until Aug 14), 2012/09/07 16:06:42]

Done.

+  audio_fifo_.reset(new AudioFifo(channels, frames));
+  audio_bus_ = AudioBus::Create(channels, read_frames);
+}
+
+AudioPullFifo::~AudioPullFifo() {
+  read_cb_.Reset();
+}
+
+void AudioPullFifo::Consume(AudioBus* destination, int frames_to_consume) {
+  DCHECK(destination);
+
+  if (frames_to_consume > audio_fifo_->frames_in_fifo()) {
+    // We don't have enough data in the FIFO to fulfill the request and must
+    // ask the provider for more data.
+    FillBuffer(frames_to_consume - audio_fifo_->frames_in_fifo());

[DaleCurtis, 2012/09/07 13:48:38]

Per my comment above, if you don't pre-consume the data out of the FIFO this can
end up in a FIFO overflow is frames_to_consume is larger than |frames|. I think
it's safer to repeatedly Consume what you can from the buffer into
|destination|. That makes this FIFO more general purpose and allows it to not
make any assumption on the request sizes of each side.

You'll need the start_frame modification like we discussed previously (and I
used in my CL) for this to work.

[henrika (OOO until Aug 14), 2012/09/07 16:06:42]

Done.

+  }
+
+  // We are now able to copy the requested amount of data to the destination.
+  audio_fifo_->Consume(destination, frames_to_consume);
+}
+
+void AudioPullFifo::FillBuffer(int frames) {
+  // Keep asking the provider to give us data until we have received at least
+  // |frames| number of audio data. Push new data to the FIFO in segments with
+  // the same size as the audio bus (set by |read_frames| in the ctor).
+  int frames_provided = 0;
+  while (frames_provided < frames) {
+    // Read audio data from the provider asking for |read_frames|.
+    read_cb_.Run(audio_bus_.get());
+
+    // Add the acquired data to the FIFO.
+    audio_fifo_->Push(audio_bus_.get());
+
+    // Keep adding to the FIFO until we have added at least |frames| number
+    // of frames.
+    frames_provided += audio_bus_->frames();
+  }
+}
+
+}  // namespace media