Update media::AudioClock API to take time since writing into account.

Update media::AudioClock API to take time since writing into account.

AudioRendererImpl will continue to function as it does today since it
always calls CurrentMediaTimestamp() inside the audio callback, hence
the time since writing is always zero.

When TimeDeltaInterpolator gets replaced by AudioRendererImpl as the
master clock inside Pipeline, we'll need a method for determining the
current media timestamp at any point in time to provide good video
synchronization that isn't affected by what the audio callback buffer
size is.

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

[scherkus (not reviewing), 2014-07-15 01:29:57]

this would also help https://codereview.chromium.org/384543002/ to handle the
case where the posted task takes a ~while before running

[DaleCurtis, 2014-07-15 18:13:15]

I also don't follow how this might help if the PostTask takes a while.  In that
case, the actual write happened at time T and the clock wasn't advanced until
time T + C.  To compensate you'd need to know when the data was actually written
and adjust the clock when the PostTask ran.

https://codereview.chromium.org/389613005/diff/1/media/filters/audio_clock.h
File media/filters/audio_clock.h (right):

https://codereview.chromium.org/389613005/diff/1/media/filters/audio_clock.h#...
media/filters/audio_clock.h:39: // Clients can provide |time_since_writing| to
simulate the passage of time
Hmm, I don't quite understand how you're going to use this.  I understand what
the unittest is trying to do, but I don't follow how callers will know "time
since writing."  Can you elaborate?

[scherkus (not reviewing), 2014-07-15 18:53:14]

On 2014/07/15 18:13:15, DaleCurtis wrote:
> I also don't follow how this might help if the PostTask takes a while.  In
that
> case, the actual write happened at time T and the clock wasn't advanced until
> time T + C.  To compensate you'd need to know when the data was actually
written
> and adjust the clock when the PostTask ran.
> 
> https://codereview.chromium.org/389613005/diff/1/media/filters/audio_clock.h
> File media/filters/audio_clock.h (right):
> 
>
https://codereview.chromium.org/389613005/diff/1/media/filters/audio_clock.h#...
> media/filters/audio_clock.h:39: // Clients can provide |time_since_writing| to
> simulate the passage of time
> Hmm, I don't quite understand how you're going to use this.  I understand what
> the unittest is trying to do, but I don't follow how callers will know "time
> since writing."  Can you elaborate?

Take a look at this version of the DidRender() CL that incorporates this CL:
https://codereview.chromium.org/384543002/diff2/20001:40001/media/filters/aud...

RenderResult stores the TimeTicks of when the actual data was written. When
notifying the rest of the system, we can measure the delta since data was
actually written to provide a better reflection of the time.

[DaleCurtis, 2014-07-15 19:24:24]

Ah, makes sense now.  lgtm

[scherkus (not reviewing), 2014-07-15 20:06:33]

The CQ bit was checked by scherkus@chromium.org

[commit-bot: I haz the power, 2014-07-15 20:08:24]

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

[commit-bot: I haz the power, 2014-07-16 00:52:29]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  ios_rel_device on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/ios_rel_device/builds...)

[commit-bot: I haz the power, 2014-07-16 05:17:26]

Change committed as 283353