Introduce PushPullFIFO class and remove other FIFOs

third_party/WebKit/Source/platform/audio/PushPullFIFO.h

Index: third_party/WebKit/Source/platform/audio/PushPullFIFO.h
diff --git a/third_party/WebKit/Source/platform/audio/PushPullFIFO.h b/third_party/WebKit/Source/platform/audio/PushPullFIFO.h
new file mode 100644
index 0000000000000000000000000000000000000000..dd930015a046a796e9dd90c7161e59dfbff9cbc3
--- /dev/null
+++ b/third_party/WebKit/Source/platform/audio/PushPullFIFO.h
@@ -0,0 +1,61 @@
+// Copyright 2016 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 PushPullFIFO_h
+#define PushPullFIFO_h
+
+#include "platform/audio/AudioBus.h"
+#include "public/platform/WebCommon.h"
+#include "wtf/Allocator.h"
+
+namespace blink {
+
+// PushPullFIFO class is an intermediate audio sample storage between
+// Blink-WebAudio and the renderer. The renderer's hardware callback buffer size
+// varies on the platform, but the WebAudio always operates by 128 frames of
+// render quantum; thus FIFO is needed.
+class BLINK_PLATFORM_EXPORT PushPullFIFO {
+  USING_FAST_MALLOC(PushPullFIFO);
+  WTF_MAKE_NONCOPYABLE(PushPullFIFO);
+
+ public:
+  PushPullFIFO(unsigned numberOfChannels, size_t fifoLength);
+  ~PushPullFIFO();
+
+  // Pushing audio data is done by the WebAudio render-backing thread. The

[o1ka, 2017/01/24 11:09:02]

Do you plan to first finalize all the index calculations and tests for them and
then tackle multithreading?

[hongchan, 2017/01/26 22:33:18]

Yes. That's the plan. 

The FIFO in this CL should be a drop-in replacement for the old FIFO, then I
will introduce the multithreading. I would like to lay out some groundwork for
it, but will not add any safety measure for multithreading in this CL.

+  // priority of this thread is lower than the actual audio device thread,
+  // thus the thread can be blocked when the audio device thread is pulling
+  // data from the FIFO.
+  void push(const AudioBus* inputBus);
+
+  // Pulling audio data is done by the audio device thread. In the case of
+  // underflow, the rest will be filled up with zeros (thus glitches). Pulling
+  // an empty FIFO is a valid operation, and the consumer will get a block of
+  // silence.
+  void pull(AudioBus* outputBus, size_t framesRequested);
+
+  int framesAvailable() const { return m_framesAvailable; }
+  int length() const { return m_fifoLength; }
+  unsigned numberOfChannels() const { return m_fifoBus->numberOfChannels(); }
+  AudioBus* bus() { return m_fifoBus.get(); }
+
+ private:
+  RefPtr<AudioBus> m_fifoBus;
+
+  // The size of the FIFO.
+  const int m_fifoLength;

[o1ka, 2017/01/24 11:09:02]

You can use "= 0" initialization here.

[hongchan, 2017/01/26 22:33:18]

Done.

+
+  // The number of frames in the FIFO actually available for pulling.
+  int m_framesAvailable;
+
+  int m_indexRead;
+  int m_indexWrite;
+
+  unsigned m_overflowCount;

[o1ka, 2017/01/24 11:09:02]

We should not use a mix of size_t, int and unsigned.
Please consider
https://chromium.googlesource.com/chromium/src/+/master/styleguide/c++/c++.md...
to decide on types, a well as
base/numerics/safe_conversions.h
base/numerics/safe_math.h
base/numerics/saturated_arithmetic.h
for safe arithmetic.

(rtoy@, re: your initial suggestion to switch from size_t to int - wouldn't it
be safe to stick with size_t and safe arithmetic?)

[hongchan, 2017/01/26 22:33:18]

This is a great resource. Thanks and we will follow this style.

However, *flowCount variables are not a number of frames or an index. These are
just internal counters for the under/overflow case. Should I still use size_t
for this purpose?

+  unsigned m_underflowCount;
+};
+
+}  // namespace blink
+
+#endif  // PushPullFIFO_h