Introduce media::AudioPushFifo and a couple of use cases (and clean-ups).

Introduce media::AudioPushFifo and a couple of use cases (and clean-ups).

The media::AudioPushFifo is yet another FIFO for audio data.  It is the
"push" version of the existing media::AudioPullFifo.

Two audio-handling implementations are switched over to using the new
AudioPushFifo in this change, with a few more to follow in later
changes:

1. Cast Receiver glue: While there was no FIFO before, one will be
required due to future refactoring work in the MediaStream audio
framework.  In addition, a time value calculation was fixed, to adhere
to the media::AudioCapturerSource interface contract.

2. content::WebAudioCapturerSource: The code using the AudioFifo
implementation was simplified by using AudioPushFifo instead.

BUG=577881, 577874
Committed: https://crrev.com/7e920b99ed879f2b08393ff0e5664f60281e274e
Cr-Commit-Position: refs/heads/master@{#377457}

[miu, 2016-02-19 01:20:16]

Patchset #1 (id:1) has been deleted

[miu, 2016-02-19 01:22:20]

Description was changed from

==========
Introduce media::AudioRechunker and three use cases (and clean-ups).

The media::AudioRechunker is yet another FIFO for audio data.  However,
unlike the others, it cannot underflow or overflow.  The API is
arguably much simpler, and the implementation can be more efficient than
the other FIFOs as well.

Three audio-handling implementations have been switched over to using
the AudioRechunker:

1. Cast Receiver glue: While there was no FIFO before, one will be
required due to future refactoring work in the MediaStream audio
framework.  In addition, a time value calculation was fixed, to adhere
to the media::AudioCapturerSource interface contract.

2. content::WebAudioCapturerSource: The code using the AudioFifo
implementation was simplified by using AudioRechunker instead.

3. content::WebRtcAudioSinkAdapter: This is another one that will be
required by later refactoring work.  Instead of a "hack" to enforce a
specific buffer size at the MediaStreamAudioSource, simply re-chunk the
audio at the sinks, and only those that specifically require the 10 ms
buffer size.

BUG=577881, 577874
==========

to

==========
Introduce media::AudioRechunker and a couple of use cases (and clean-ups).

The media::AudioRechunker is yet another FIFO for audio data.  However,
unlike the others, it cannot underflow or overflow.  The API is
arguably much simpler, and the implementation can be more efficient than
the other FIFOs as well.

Two audio-handling implementations are switched over to using the new
AudioRechunker in this change, with a few more to follow in later
changes:

1. Cast Receiver glue: While there was no FIFO before, one will be
required due to future refactoring work in the MediaStream audio
framework.  In addition, a time value calculation was fixed, to adhere
to the media::AudioCapturerSource interface contract.

2. content::WebAudioCapturerSource: The code using the AudioFifo
implementation was simplified by using AudioRechunker instead.

BUG=577881, 577874
==========

[miu, 2016-02-19 01:29:04]

miu@chromium.org changed reviewers:
+ dalecurtis@chromium.org, olka@chromium.org, xjz@chromium.org

[miu, 2016-02-19 01:29:05]

dalecurtis: PTAL at media/*

olka: PTAL at content/renderer/media/webaudio_capturer_source.*

xjz: PTAL at all files with "cast" in the name.

[o1ka, 2016-02-19 09:35:41]

olka@chromium.org changed reviewers:
+ grunell@chromium.org

[o1ka, 2016-02-19 09:36:54]

adding grunell as a reviewer - I'm sure he is interested in this change

[DaleCurtis, 2016-02-20 00:07:22]

It seems like this is the opposite of AudioPullFIFO. I.e. it's a AudioPushFifo?
AudioBlockFIFO allows copies to be avoided while deinterleaving.  I'm not sure
you can replace it with this.

Since we already have pull-fifo it seems logical that this should be named
audio_push_fifo instead of rechunker which is a new term :)

https://codereview.chromium.org/1714593003/diff/40001/media/base/audio_block_...
File media/base/audio_block_fifo.h (right):

https://codereview.chromium.org/1714593003/diff/40001/media/base/audio_block_...
media/base/audio_block_fifo.h:20: //
Do you plan to port and remove existing instances? Should we file a bug to track
this?

https://codereview.chromium.org/1714593003/diff/40001/media/base/audio_fifo.h
File media/base/audio_fifo.h (right):

https://codereview.chromium.org/1714593003/diff/40001/media/base/audio_fifo.h...
media/base/audio_fifo.h:19: //
Ditto.

[xjz, 2016-02-20 01:53:05]

lgtm. nits:

https://codereview.chromium.org/1714593003/diff/40001/chrome/renderer/media/c...
File chrome/renderer/media/cast_receiver_audio_valve.cc (right):

https://codereview.chromium.org/1714593003/diff/40001/chrome/renderer/media/c...
chrome/renderer/media/cast_receiver_audio_valve.cc:22:
rechunker_.SetSampleRate(params.sample_rate());
Need to check returning true?

https://codereview.chromium.org/1714593003/diff/40001/media/base/audio_rechun...
File media/base/audio_rechunker.cc (right):

https://codereview.chromium.org/1714593003/diff/40001/media/base/audio_rechun...
media/base/audio_rechunker.cc:27: audio_queue_.reset();
Same as the other comment, I think here also assumes that the frames in each
Push can be exactly re-chunked?

https://codereview.chromium.org/1714593003/diff/40001/media/base/audio_rechun...
media/base/audio_rechunker.cc:75: if (pending_frames_ == output_frames_) {
Does here assume that for each Push, the input frames can always be exactly
re-chunked? i.e., there is no such condition: (pending_frames_ < output_frames_)
&& (source_pos == input_bus.frames()) ?

[o1ka, 2016-02-22 13:04:48]

Looks good, could you explain more on "exactly re-chunk" vs "not exactly"? How
clients are supposed to deal with that?

https://codereview.chromium.org/1714593003/diff/40001/content/renderer/media/...
File content/renderer/media/webaudio_capturer_source.cc (right):

https://codereview.chromium.org/1714593003/diff/40001/content/renderer/media/...
content/renderer/media/webaudio_capturer_source.cc:110:
rechunker_.Push(*wrapper_bus_, reference_time - base::TimeTicks());
I like how neat it becomes!

https://codereview.chromium.org/1714593003/diff/40001/media/base/audio_rechun...
File media/base/audio_rechunker.cc (right):

https://codereview.chromium.org/1714593003/diff/40001/media/base/audio_rechun...
media/base/audio_rechunker.cc:56: // Repeatedly fill up |audio_queue_| with more
sample frames from |input_bus|
I find the part below a bit difficult to read due to naming.

https://codereview.chromium.org/1714593003/diff/40001/media/base/audio_rechun...
media/base/audio_rechunker.cc:59: int source_pos = 0;
Can it be named |input_bus_offset| or something like this to reflect its actual
meaning and to associate it with |input_bus|?

https://codereview.chromium.org/1714593003/diff/40001/media/base/audio_rechun...
media/base/audio_rechunker.cc:62: const int frames_to_push =
|frames_to_queue|? As I see it, frames_to_push are in the input_bus and/or in
the audio_queue, depending on the viewpoint.

https://codereview.chromium.org/1714593003/diff/40001/media/base/audio_rechun...
media/base/audio_rechunker.cc:68: audio_queue_.get());
It would be also nice to somehow associate |pending_frames_| with |audio_queue_|
through naming to increase readability. Probably, just |queued_frames_|.

https://codereview.chromium.org/1714593003/diff/40001/media/base/audio_rechun...
media/base/audio_rechunker.cc:80: }
To improve readability, it would be nice to have a comment that otherwise it
means that  (pending_frames_ < output_frames_) due to the way frames_to_push are
calculated.

https://codereview.chromium.org/1714593003/diff/40001/media/base/audio_rechun...
File media/base/audio_rechunker.h (right):

https://codereview.chromium.org/1714593003/diff/40001/media/base/audio_rechun...
media/base/audio_rechunker.h:27: using RechunkedAudioCallback =
I think that the fact that |output| is of output_frames() size which can change
only on SetSampleRate() worth mentioning here.

https://codereview.chromium.org/1714593003/diff/40001/media/base/audio_rechun...
media/base/audio_rechunker.h:49: bool SetSampleRate(int sample_rate);
What are the consequences of |false| return value for the clients? How they are
supposed to use it - any recommendations?

[miu, 2016-02-23 04:24:15]

Description was changed from

==========
Introduce media::AudioRechunker and a couple of use cases (and clean-ups).

The media::AudioRechunker is yet another FIFO for audio data.  However,
unlike the others, it cannot underflow or overflow.  The API is
arguably much simpler, and the implementation can be more efficient than
the other FIFOs as well.

Two audio-handling implementations are switched over to using the new
AudioRechunker in this change, with a few more to follow in later
changes:

1. Cast Receiver glue: While there was no FIFO before, one will be
required due to future refactoring work in the MediaStream audio
framework.  In addition, a time value calculation was fixed, to adhere
to the media::AudioCapturerSource interface contract.

2. content::WebAudioCapturerSource: The code using the AudioFifo
implementation was simplified by using AudioRechunker instead.

BUG=577881, 577874
==========

to

==========
Introduce media::AudioPushFifo and a couple of use cases (and clean-ups).

The media::AudioPushFifo is yet another FIFO for audio data.  It is the
"push" version of the existing media::AudioPullFifo.

Two audio-handling implementations are switched over to using the new
AudioPushFifo in this change, with a few more to follow in later
changes:

1. Cast Receiver glue: While there was no FIFO before, one will be
required due to future refactoring work in the MediaStream audio
framework.  In addition, a time value calculation was fixed, to adhere
to the media::AudioCapturerSource interface contract.

2. content::WebAudioCapturerSource: The code using the AudioFifo
implementation was simplified by using AudioPushFifo instead.

BUG=577881, 577874
==========

[miu, 2016-02-23 04:27:41]

Now that Dale pointed out that there's an AudioPullFifo, I turned my
AudioRechunker into an AudioPushFifo.  I took the timing calculations out of it
as well, and made its interface look similar to AudioPullFifo.  I think this has
cleared up a few other points of confusion from other reviewers.

PTAL at the leaner-and-meaner result.  :)

https://codereview.chromium.org/1714593003/diff/40001/chrome/renderer/media/c...
File chrome/renderer/media/cast_receiver_audio_valve.cc (right):

https://codereview.chromium.org/1714593003/diff/40001/chrome/renderer/media/c...
chrome/renderer/media/cast_receiver_audio_valve.cc:22:
rechunker_.SetSampleRate(params.sample_rate());
On 2016/02/20 01:53:04, xjz wrote:
> Need to check returning true?

No longer applicable.

https://codereview.chromium.org/1714593003/diff/40001/content/renderer/media/...
File content/renderer/media/webaudio_capturer_source.cc (right):

https://codereview.chromium.org/1714593003/diff/40001/content/renderer/media/...
content/renderer/media/webaudio_capturer_source.cc:110:
rechunker_.Push(*wrapper_bus_, reference_time - base::TimeTicks());
On 2016/02/22 13:04:47, o1ka wrote:
> I like how neat it becomes!

Acknowledged.

https://codereview.chromium.org/1714593003/diff/40001/media/base/audio_block_...
File media/base/audio_block_fifo.h (right):

https://codereview.chromium.org/1714593003/diff/40001/media/base/audio_block_...
media/base/audio_block_fifo.h:20: //
On 2016/02/20 00:07:22, DaleCurtis wrote:
> Do you plan to port and remove existing instances? Should we file a bug to
track
> this?

I don't have the available cycles, myself.  I've removed these comments for now.

https://codereview.chromium.org/1714593003/diff/40001/media/base/audio_fifo.h
File media/base/audio_fifo.h (right):

https://codereview.chromium.org/1714593003/diff/40001/media/base/audio_fifo.h...
media/base/audio_fifo.h:19: //
On 2016/02/20 00:07:22, DaleCurtis wrote:
> Ditto.

Done.

https://codereview.chromium.org/1714593003/diff/40001/media/base/audio_rechun...
File media/base/audio_rechunker.cc (right):

https://codereview.chromium.org/1714593003/diff/40001/media/base/audio_rechun...
media/base/audio_rechunker.cc:27: audio_queue_.reset();
On 2016/02/20 01:53:04, xjz wrote:
> Same as the other comment, I think here also assumes that the frames in each
> Push can be exactly re-chunked?

That's not the assumption.  See my reply to your other comment.

https://codereview.chromium.org/1714593003/diff/40001/media/base/audio_rechun...
media/base/audio_rechunker.cc:56: // Repeatedly fill up |audio_queue_| with more
sample frames from |input_bus|
On 2016/02/22 13:04:47, o1ka wrote:
> I find the part below a bit difficult to read due to naming.

Acknowledged.

https://codereview.chromium.org/1714593003/diff/40001/media/base/audio_rechun...
media/base/audio_rechunker.cc:59: int source_pos = 0;
On 2016/02/22 13:04:47, o1ka wrote:
> Can it be named |input_bus_offset| or something like this to reflect its
actual
> meaning and to associate it with |input_bus|?

Done.  Changed to input_offset.

https://codereview.chromium.org/1714593003/diff/40001/media/base/audio_rechun...
media/base/audio_rechunker.cc:62: const int frames_to_push =
On 2016/02/22 13:04:47, o1ka wrote:
> |frames_to_queue|? As I see it, frames_to_push are in the input_bus and/or in
> the audio_queue, depending on the viewpoint.

Done.  Changed to frames_to_enqueue.

https://codereview.chromium.org/1714593003/diff/40001/media/base/audio_rechun...
media/base/audio_rechunker.cc:68: audio_queue_.get());
On 2016/02/22 13:04:47, o1ka wrote:
> It would be also nice to somehow associate |pending_frames_| with
|audio_queue_|
> through naming to increase readability. Probably, just |queued_frames_|.

Done.

https://codereview.chromium.org/1714593003/diff/40001/media/base/audio_rechun...
media/base/audio_rechunker.cc:75: if (pending_frames_ == output_frames_) {
On 2016/02/20 01:53:04, xjz wrote:
> Does here assume that for each Push, the input frames can always be exactly
> re-chunked? i.e., there is no such condition: (pending_frames_ <
output_frames_)
> && (source_pos == input_bus.frames()) ?

No, that's not the assumption at all.  The number of input frames can be
anything: smaller, exactly the same, or larger than the number of output frames.
 The code handles all of these cases.

In other words, it is possible for there to be left-over data from one Push()
call that will be delivered later when the next Push() call is made.

https://codereview.chromium.org/1714593003/diff/40001/media/base/audio_rechun...
media/base/audio_rechunker.cc:80: }
On 2016/02/22 13:04:47, o1ka wrote:
> To improve readability, it would be nice to have a comment that otherwise it
> means that  (pending_frames_ < output_frames_) due to the way frames_to_push
are
> calculated.

Done.

[DaleCurtis, 2016-02-23 20:34:26]

Just reviewed AudioPullFifo, lgtm do you want to support any kind of flush
functionality?

https://codereview.chromium.org/1714593003/diff/60001/media/base/audio_push_f...
File media/base/audio_push_fifo.cc (right):

https://codereview.chromium.org/1714593003/diff/60001/media/base/audio_push_f...
media/base/audio_push_fifo.cc:37: if (!audio_queue_ || audio_queue_->channels()
!= input_bus.channels())
Do you want to document that channel changes will throw away previous data?

https://codereview.chromium.org/1714593003/diff/60001/media/base/audio_push_f...
File media/base/audio_push_fifo.h (right):

https://codereview.chromium.org/1714593003/diff/60001/media/base/audio_push_f...
media/base/audio_push_fifo.h:20: // shifts reference timestamps to account for
any samples that were pending in
Remove comments on reference timestamps?

https://codereview.chromium.org/1714593003/diff/60001/media/base/audio_push_f...
media/base/audio_push_fifo.h:31: // call to Push().  Clients can use this to
adjust timestmaps.
timestamps.

https://codereview.chromium.org/1714593003/diff/60001/media/base/audio_push_f...
media/base/audio_push_fifo.h:33: base::Callback<void(const AudioBus& output_bus,
int frame_offset)>;
We typically call this frame_delay (see SincResampler/AudioPullFifo)

[xjz, 2016-02-23 22:03:02]

lgtm

https://codereview.chromium.org/1714593003/diff/60001/media/base/audio_push_f...
File media/base/audio_push_fifo.cc (right):

https://codereview.chromium.org/1714593003/diff/60001/media/base/audio_push_f...
media/base/audio_push_fifo.cc:21: audio_queue_.reset();
Is it possible that there are still pending packets when changing the sample
rate?

[miu, 2016-02-23 23:30:18]

Patchset #4 (id:80001) has been deleted

[miu, 2016-02-23 23:32:34]

https://codereview.chromium.org/1714593003/diff/60001/media/base/audio_push_f...
File media/base/audio_push_fifo.cc (right):

https://codereview.chromium.org/1714593003/diff/60001/media/base/audio_push_f...
media/base/audio_push_fifo.cc:21: audio_queue_.reset();
On 2016/02/23 22:03:02, xjz wrote:
> Is it possible that there are still pending packets when changing the sample
> rate?

Yes.  As Dale suggested, I've added a Flush() method just in case some clients
would be interested in flushing those pending frames out first.

https://codereview.chromium.org/1714593003/diff/60001/media/base/audio_push_f...
media/base/audio_push_fifo.cc:37: if (!audio_queue_ || audio_queue_->channels()
!= input_bus.channels())
On 2016/02/23 20:34:26, DaleCurtis wrote:
> Do you want to document that channel changes will throw away previous data?

Done.  In header comments for Push() method.

https://codereview.chromium.org/1714593003/diff/60001/media/base/audio_push_f...
File media/base/audio_push_fifo.h (right):

https://codereview.chromium.org/1714593003/diff/60001/media/base/audio_push_f...
media/base/audio_push_fifo.h:20: // shifts reference timestamps to account for
any samples that were pending in
On 2016/02/23 20:34:26, DaleCurtis wrote:
> Remove comments on reference timestamps?

Done.

https://codereview.chromium.org/1714593003/diff/60001/media/base/audio_push_f...
media/base/audio_push_fifo.h:31: // call to Push().  Clients can use this to
adjust timestmaps.
On 2016/02/23 20:34:26, DaleCurtis wrote:
> timestamps.

Done.

https://codereview.chromium.org/1714593003/diff/60001/media/base/audio_push_f...
media/base/audio_push_fifo.h:33: base::Callback<void(const AudioBus& output_bus,
int frame_offset)>;
On 2016/02/23 20:34:26, DaleCurtis wrote:
> We typically call this frame_delay (see SincResampler/AudioPullFifo)

Done.

[o1ka, 2016-02-24 09:23:30]

nice! lgtm.

https://codereview.chromium.org/1714593003/diff/100001/media/base/audio_push_...
File media/base/audio_push_fifo.h (right):

https://codereview.chromium.org/1714593003/diff/100001/media/base/audio_push_...
media/base/audio_push_fifo.h:45: void Reset(int frames_per_buffer);
match parameter name with |output_frames_| member name?

https://codereview.chromium.org/1714593003/diff/100001/media/base/audio_push_...
media/base/audio_push_fifo.h:62: int output_frames_;
frames_per_buffer_ seems to be a more common name for this, and you even used it
for Reset() parameter already.
(sorry missed this at the previous round)

[Irfan, 2016-02-24 19:04:29]

isheriff@chromium.org changed reviewers:
+ isheriff@chromium.org

[Irfan, 2016-02-24 19:04:30]

couple nits from a quick scan

https://codereview.chromium.org/1714593003/diff/100001/content/renderer/media...
File content/renderer/media/webaudio_capturer_source.h (right):

https://codereview.chromium.org/1714593003/diff/100001/content/renderer/media...
content/renderer/media/webaudio_capturer_source.h:96: //
DeviliverRebufferedAudio().
DeliverRebufferedAudio

https://codereview.chromium.org/1714593003/diff/100001/media/base/audio_push_...
File media/base/audio_push_fifo.h (right):

https://codereview.chromium.org/1714593003/diff/100001/media/base/audio_push_...
media/base/audio_push_fifo.h:33: // Creates a new AudioPushFifo delivers
re-buffered audio by running
AudioPushFifo which delivers ?

[miu, 2016-02-24 22:12:36]

Patchset #5 (id:120001) has been deleted

[miu, 2016-02-24 22:16:42]

Thanks irfan and o1ka.  All comments addressed.

https://codereview.chromium.org/1714593003/diff/100001/content/renderer/media...
File content/renderer/media/webaudio_capturer_source.h (right):

https://codereview.chromium.org/1714593003/diff/100001/content/renderer/media...
content/renderer/media/webaudio_capturer_source.h:96: //
DeviliverRebufferedAudio().
On 2016/02/24 19:04:30, Irfan wrote:
> DeliverRebufferedAudio

Done.

https://codereview.chromium.org/1714593003/diff/100001/media/base/audio_push_...
File media/base/audio_push_fifo.h (right):

https://codereview.chromium.org/1714593003/diff/100001/media/base/audio_push_...
media/base/audio_push_fifo.h:33: // Creates a new AudioPushFifo delivers
re-buffered audio by running
On 2016/02/24 19:04:30, Irfan wrote:
> AudioPushFifo which delivers ?

Done.

https://codereview.chromium.org/1714593003/diff/100001/media/base/audio_push_...
media/base/audio_push_fifo.h:45: void Reset(int frames_per_buffer);
On 2016/02/24 09:23:30, o1ka wrote:
> match parameter name with |output_frames_| member name?

Done.

https://codereview.chromium.org/1714593003/diff/100001/media/base/audio_push_...
media/base/audio_push_fifo.h:62: int output_frames_;
On 2016/02/24 09:23:30, o1ka wrote:
> frames_per_buffer_ seems to be a more common name for this, and you even used
it
> for Reset() parameter already.
> (sorry missed this at the previous round)

Done.

[miu, 2016-02-24 22:16:49]

The CQ bit was checked by miu@chromium.org

[miu, 2016-02-24 22:16:49]

The patchset sent to the CQ was uploaded after l-g-t-m from xjz@chromium.org,
dalecurtis@chromium.org, olka@chromium.org
Link to the patchset: https://codereview.chromium.org/1714593003/#ps140001
(title: "addressed last round of comments")

[commit-bot: I haz the power, 2016-02-24 22:17:36]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1714593003/140001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1714593003/140001

[commit-bot: I haz the power, 2016-02-24 22:35:12]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-02-24 22:35:13]

Try jobs failed on following builders:
  cast_shell_android on tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/cast_shell_a...)
  cast_shell_linux on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)
  chromeos_amd64-generic_chromium_compile_only_ng on tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_amd64-...)
  linux_chromium_compile_dbg_32_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[miu, 2016-02-25 00:13:45]

The CQ bit was checked by miu@chromium.org

[miu, 2016-02-25 00:13:45]

The patchset sent to the CQ was uploaded after l-g-t-m from xjz@chromium.org,
dalecurtis@chromium.org, olka@chromium.org
Link to the patchset: https://codereview.chromium.org/1714593003/#ps160001
(title: "Fix unittest compile breakage caused by recent method rename.")

[commit-bot: I haz the power, 2016-02-25 00:17:08]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1714593003/160001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1714593003/160001

[commit-bot: I haz the power, 2016-02-25 01:39:30]

Description was changed from

==========
Introduce media::AudioPushFifo and a couple of use cases (and clean-ups).

The media::AudioPushFifo is yet another FIFO for audio data.  It is the
"push" version of the existing media::AudioPullFifo.

Two audio-handling implementations are switched over to using the new
AudioPushFifo in this change, with a few more to follow in later
changes:

1. Cast Receiver glue: While there was no FIFO before, one will be
required due to future refactoring work in the MediaStream audio
framework.  In addition, a time value calculation was fixed, to adhere
to the media::AudioCapturerSource interface contract.

2. content::WebAudioCapturerSource: The code using the AudioFifo
implementation was simplified by using AudioPushFifo instead.

BUG=577881, 577874
==========

to

==========
Introduce media::AudioPushFifo and a couple of use cases (and clean-ups).

The media::AudioPushFifo is yet another FIFO for audio data.  It is the
"push" version of the existing media::AudioPullFifo.

Two audio-handling implementations are switched over to using the new
AudioPushFifo in this change, with a few more to follow in later
changes:

1. Cast Receiver glue: While there was no FIFO before, one will be
required due to future refactoring work in the MediaStream audio
framework.  In addition, a time value calculation was fixed, to adhere
to the media::AudioCapturerSource interface contract.

2. content::WebAudioCapturerSource: The code using the AudioFifo
implementation was simplified by using AudioPushFifo instead.

BUG=577881, 577874
==========

[commit-bot: I haz the power, 2016-02-25 01:39:31]

Committed patchset #6 (id:160001)

[commit-bot: I haz the power, 2016-02-25 01:40:42]

Description was changed from

==========
Introduce media::AudioPushFifo and a couple of use cases (and clean-ups).

The media::AudioPushFifo is yet another FIFO for audio data.  It is the
"push" version of the existing media::AudioPullFifo.

Two audio-handling implementations are switched over to using the new
AudioPushFifo in this change, with a few more to follow in later
changes:

1. Cast Receiver glue: While there was no FIFO before, one will be
required due to future refactoring work in the MediaStream audio
framework.  In addition, a time value calculation was fixed, to adhere
to the media::AudioCapturerSource interface contract.

2. content::WebAudioCapturerSource: The code using the AudioFifo
implementation was simplified by using AudioPushFifo instead.

BUG=577881, 577874
==========

to

==========
Introduce media::AudioPushFifo and a couple of use cases (and clean-ups).

The media::AudioPushFifo is yet another FIFO for audio data.  It is the
"push" version of the existing media::AudioPullFifo.

Two audio-handling implementations are switched over to using the new
AudioPushFifo in this change, with a few more to follow in later
changes:

1. Cast Receiver glue: While there was no FIFO before, one will be
required due to future refactoring work in the MediaStream audio
framework.  In addition, a time value calculation was fixed, to adhere
to the media::AudioCapturerSource interface contract.

2. content::WebAudioCapturerSource: The code using the AudioFifo
implementation was simplified by using AudioPushFifo instead.

BUG=577881, 577874

Committed: https://crrev.com/7e920b99ed879f2b08393ff0e5664f60281e274e
Cr-Commit-Position: refs/heads/master@{#377457}
==========

[commit-bot: I haz the power, 2016-02-25 01:40:44]

Patchset 6 (id:??) landed as
https://crrev.com/7e920b99ed879f2b08393ff0e5664f60281e274e
Cr-Commit-Position: refs/heads/master@{#377457}