Always run AudioRendererImpl's flush callback asynchronously.

Always run AudioRendererImpl's flush callback asynchronously.

It's possible to hit Pipeline's DCHECK that verifies renderers have
reset their buffering state after flushing since AudioRendererImpl
always runs buffering state changes asynchronously but ran the flush
callback synchronously.

BUG=389104
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=281156

[scherkus (not reviewing), 2014-07-02 20:35:29]

tricky :\

[xhwang, 2014-07-02 20:51:40]

This CL lgtm. But in VRI, the buffering_state_cb_ isn't posted. We probably
should make ARI and VRI as consistent as possible.

[scherkus (not reviewing), 2014-07-02 20:54:20]

On 2014/07/02 20:51:40, xhwang wrote:
> This CL lgtm. But in VRI, the buffering_state_cb_ isn't posted. We probably
> should make ARI and VRI as consistent as possible.

ideally ARI should be more like VRI where most things run on a single thread ...
but today it isn't because ARI uses a lot of locking between the audio callback
thread and the media thread

this makes thing a bit uglier until ARI can get cleaned up some more

[xhwang, 2014-07-02 20:58:12]

On 2014/07/02 20:54:20, scherkus wrote:
> On 2014/07/02 20:51:40, xhwang wrote:
> > This CL lgtm. But in VRI, the buffering_state_cb_ isn't posted. We probably
> > should make ARI and VRI as consistent as possible.
> 
> ideally ARI should be more like VRI where most things run on a single thread
...
> but today it isn't because ARI uses a lot of locking between the audio
callback
> thread and the media thread
> 
> this makes thing a bit uglier until ARI can get cleaned up some more

I see. Thanks for the explanation.

[scherkus (not reviewing), 2014-07-02 21:05:26]

The CQ bit was checked by scherkus@chromium.org

[commit-bot: I haz the power, 2014-07-02 21:06:03]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/scherkus@chromium.org/363093003/1

[commit-bot: I haz the power, 2014-07-03 03:28:14]

Change committed as 281156