Use AudioClock to determine when audio playback has ended.

Use AudioClock to determine when audio playback has ended.

The old mechanism of estimating the wall clock time isn't as accurate as
the frame-level information tracked inside AudioClock. For example,
AudioClock properly handles situations where the playback rate changes
over time.

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

[scherkus (not reviewing), 2014-07-10 00:33:44]

I'm still doing a bunch of manual testing, but wanted to gather your thoughts.

So far the audio loop benchmark is still getting very similar numbers.

https://codereview.chromium.org/382633005/diff/1/media/filters/audio_renderer...
File media/filters/audio_renderer_impl.h (left):

https://codereview.chromium.org/382633005/diff/1/media/filters/audio_renderer...
media/filters/audio_renderer_impl.h:275: size_t total_frames_filled_;
apparently this variable was completely unused

[DaleCurtis, 2014-07-10 01:44:06]

\o/  Love it!  I was hoping you could do this when you first brought up the
AudioClock.

Yeah, I've tested methods similar to this before and had similar luck with that
benchmark.  On Linux the delay data seems to be off a fair bit.  I've never been
able to find a problem with our implementation though.  You can experiment with
this by ignoring the audio_delay_milliseconds value.

Have you tried running this on Windows or Mac?  You might see a few ms of
improvement there.

https://codereview.chromium.org/382633005/diff/1/media/filters/audio_renderer...
File media/filters/audio_renderer_impl.h (left):

https://codereview.chromium.org/382633005/diff/1/media/filters/audio_renderer...
media/filters/audio_renderer_impl.h:275: size_t total_frames_filled_;
On 2014/07/10 00:33:44, scherkus wrote:
> apparently this variable was completely unused

Haha, yeah, I've removed it a couple times locally, but I guess I forgot to
upload those patch sets. Thanks!

[DaleCurtis, 2014-07-10 01:44:13]

lgtm

[scherkus (not reviewing), 2014-07-10 16:21:16]

thanks for the review!

yeah I've tested as much as I can on mac and windows and as far as I can tell
things are still working as they should be.

I'm satisfied enough to let this land!

[scherkus (not reviewing), 2014-07-10 16:21:20]

The CQ bit was checked by scherkus@chromium.org

[commit-bot: I haz the power, 2014-07-10 16:23:41]

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

[commit-bot: I haz the power, 2014-07-10 17:54:47]

Change committed as 282376

[DaleCurtis, 2014-07-10 19:01:38]

Awesome, for clarity: I muddled what I was originally trying to say:  The
initial playback delay impacts the loop delay, because the total loop time
includes the initial playback delay.

I.e., we start the measurement timer on playing, but nothing actually gets
played until we've exhausted the initial playback delay.  As such we always end
up with a loop time dominated by the initial delay when it's large.