Introduce media::AudioClock::WallTimeForTimestamp().

Introduce media::AudioClock::TimeUntilPlayback().

Given a media timestamp within {front,back}_timestamp(), will return the amount
of wall time until being played by the audio hardware.

This function will be used with the upcoming video frame scheduler.

BUG=370634
Committed: https://crrev.com/a3b173711088d929780c8dcfe94e28db1766e938
Cr-Commit-Position: refs/heads/master@{#296052}

[scherkus (not reviewing), 2014-09-19 22:31:49]

Patchset #1 (id:1) has been deleted

[scherkus (not reviewing), 2014-09-19 22:44:43]

Patchset #1 (id:20001) has been deleted

[scherkus (not reviewing), 2014-09-19 22:44:48]

Patchset #1 (id:40001) has been deleted

[scherkus (not reviewing), 2014-09-19 22:46:29]

scherkus@chromium.org changed reviewers:
+ dalecurtis@chromium.org

[DaleCurtis, 2014-09-20 00:17:12]

https://codereview.chromium.org/591603003/diff/60001/media/filters/audio_cloc...
File media/filters/audio_clock.cc (right):

https://codereview.chromium.org/591603003/diff/60001/media/filters/audio_cloc...
media/filters/audio_clock.cc:107: if (media_time >= timestamp)
Should never be true?  Which should allow the lower condition to merge into the
one above minus the i == 0.

https://codereview.chromium.org/591603003/diff/60001/media/filters/audio_cloc...
media/filters/audio_clock.cc:121: 
I'm wary of all these conversions back and forth from TimeDelta, though it's
likely fine for integer playback rates.  You can simplify all this to the
following which is both faster (~40% according to a quick unittest) and more
accurate:

int64_t frames_until_timestamp = 0;
double timestamp_us = timestamp.InMicroseconds();
double media_time = front_timestamp_.InMicroseconds();

for (...) {
  if (buffered_[i].playback_rate == 0) {
    frames_until_timestamp += buffered_[i].frames;
    continue;
  }

  const double delta = 
      buffered[i].frames * buffered[i].playbackrate * microseconds_per_frame_;
  const double max_media_time = media_time + delta;
  if (timestamp_us <= max_media_time) {
    frames_until_timestamp +=
        buffered[i].frames * (timestamp_us - media_time) / delta;
    break;
  }

  media_time = max_media_time;
  frames_until_timestamp += buffered_[i].frames;
}

return FromMicroseconds(frames_until_timestamp);

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

https://codereview.chromium.org/591603003/diff/60001/media/filters/audio_cloc...
media/filters/audio_clock.h:91: base::TimeDelta
WallTimeForTimestamp(base::TimeDelta timestamp) const;
What do you think about TimeToPlayback(), TimeUntilAudible(), some variation
there of?  WallTimeForTimestamp just seems kind of obtuse and this class already
introduces some non-obvious concepts.

https://codereview.chromium.org/591603003/diff/60001/media/filters/audio_cloc...
File media/filters/audio_clock_unittest.cc (right):

https://codereview.chromium.org/591603003/diff/60001/media/filters/audio_cloc...
media/filters/audio_clock_unittest.cc:326: //
+------------+---------+------------+-----------+------------+-----------+
As discussed, this diagram is wrong, here's a fixed'ish one for my own
edification:

  // 2000
  // +---------+------------+-----------+------------+-----------+
  // | 10 @ 1x | 10 silence | 10 @ 0.5x | 10 silence | 10 @ 2.0x |
  // +---------+------------+-----------+------------+-----------+
  // Media:   1000        1000         1500        1500         3500
  // Wall:    3000        4000         5000        6000         7000

[scherkus (not reviewing), 2014-09-22 18:34:13]

https://codereview.chromium.org/591603003/diff/60001/media/filters/audio_cloc...
File media/filters/audio_clock.cc (right):

https://codereview.chromium.org/591603003/diff/60001/media/filters/audio_cloc...
media/filters/audio_clock.cc:107: if (media_time >= timestamp)
On 2014/09/20 00:17:12, DaleCurtis wrote:
> Should never be true?  Which should allow the lower condition to merge into
the
> one above minus the i == 0.

Yeah code got a little mucked up after a few iterations. Rewritten using your
suggestion below.

https://codereview.chromium.org/591603003/diff/60001/media/filters/audio_cloc...
media/filters/audio_clock.cc:121: 
On 2014/09/20 00:17:12, DaleCurtis wrote:
> I'm wary of all these conversions back and forth from TimeDelta, though it's
> likely fine for integer playback rates.  You can simplify all this to the
> following which is both faster (~40% according to a quick unittest) and more
> accurate:
> 
> int64_t frames_until_timestamp = 0;
> double timestamp_us = timestamp.InMicroseconds();
> double media_time = front_timestamp_.InMicroseconds();
> 
> for (...) {
>   if (buffered_[i].playback_rate == 0) {
>     frames_until_timestamp += buffered_[i].frames;
>     continue;
>   }
> 
>   const double delta = 
>       buffered[i].frames * buffered[i].playbackrate * microseconds_per_frame_;
>   const double max_media_time = media_time + delta;
>   if (timestamp_us <= max_media_time) {
>     frames_until_timestamp +=
>         buffered[i].frames * (timestamp_us - media_time) / delta;
>     break;
>   }
> 
>   media_time = max_media_time;
>   frames_until_timestamp += buffered_[i].frames;
> }
> 
> return FromMicroseconds(frames_until_timestamp);

Done.

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

https://codereview.chromium.org/591603003/diff/60001/media/filters/audio_cloc...
media/filters/audio_clock.h:91: base::TimeDelta
WallTimeForTimestamp(base::TimeDelta timestamp) const;
On 2014/09/20 00:17:12, DaleCurtis wrote:
> What do you think about TimeToPlayback(), TimeUntilAudible(), some variation
> there of?  WallTimeForTimestamp just seems kind of obtuse and this class
already
> introduces some non-obvious concepts.

picked TimeUntilPlayback()

https://codereview.chromium.org/591603003/diff/60001/media/filters/audio_cloc...
File media/filters/audio_clock_unittest.cc (right):

https://codereview.chromium.org/591603003/diff/60001/media/filters/audio_cloc...
media/filters/audio_clock_unittest.cc:326: //
+------------+---------+------------+-----------+------------+-----------+
On 2014/09/20 00:17:12, DaleCurtis wrote:
> As discussed, this diagram is wrong, here's a fixed'ish one for my own
> edification:
> 
>   // 2000
>   // +---------+------------+-----------+------------+-----------+
>   // | 10 @ 1x | 10 silence | 10 @ 0.5x | 10 silence | 10 @ 2.0x |
>   // +---------+------------+-----------+------------+-----------+
>   // Media:   1000        1000         1500        1500         3500
>   // Wall:    3000        4000         5000        6000         7000

Done.

[DaleCurtis, 2014-09-22 18:48:57]

lgtm

https://codereview.chromium.org/591603003/diff/100001/media/filters/audio_clo...
File media/filters/audio_clock_unittest.cc (right):

https://codereview.chromium.org/591603003/diff/100001/media/filters/audio_clo...
media/filters/audio_clock_unittest.cc:44: timestamp_ms)).InMilliseconds();
Weird formatting, did clang-format do this?

[scherkus (not reviewing), 2014-09-22 18:49:57]

https://codereview.chromium.org/591603003/diff/100001/media/filters/audio_clo...
File media/filters/audio_clock_unittest.cc (right):

https://codereview.chromium.org/591603003/diff/100001/media/filters/audio_clo...
media/filters/audio_clock_unittest.cc:44: timestamp_ms)).InMilliseconds();
On 2014/09/22 18:48:57, DaleCurtis wrote:
> Weird formatting, did clang-format do this?

It did!

[scherkus (not reviewing), 2014-09-22 18:50:01]

The CQ bit was checked by scherkus@chromium.org

[commit-bot: I haz the power, 2014-09-22 18:51:01]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/591603003/100001

[commit-bot: I haz the power, 2014-09-22 20:51:06]

Committed patchset #3 (id:100001) as a2ca4c7ec1bcedb774daf08b1e64ffd9155530bb

[commit-bot: I haz the power, 2014-09-22 20:52:06]

Patchset 3 (id:??) landed as
https://crrev.com/a3b173711088d929780c8dcfe94e28db1766e938
Cr-Commit-Position: refs/heads/master@{#296052}