Fix VirtualAudioInputStream callback timing issues.

media/audio/virtual_audio_input_stream.cc

Index: media/audio/virtual_audio_input_stream.cc
diff --git a/media/audio/virtual_audio_input_stream.cc b/media/audio/virtual_audio_input_stream.cc
index 4f2f9bd04fb84a4619766597777c75665b5641c6..06266b0f557e320e76497c3d7a76cbaa948d7133 100644
--- a/media/audio/virtual_audio_input_stream.cc
+++ b/media/audio/virtual_audio_input_stream.cc
@@ -85,6 +85,7 @@ bool VirtualAudioInputStream::Open() {
 void VirtualAudioInputStream::Start(AudioInputCallback* callback) {
   DCHECK(message_loop_->BelongsToCurrentThread());
   callback_ = callback;
+  next_read_time_ = base::Time::Now();
   on_more_data_cb_.Reset(base::Bind(&VirtualAudioInputStream::ReadAudio,
                                     base::Unretained(this)));
   audio_manager_->GetMessageLoop()->PostTask(FROM_HERE,
@@ -139,9 +140,20 @@ void VirtualAudioInputStream::ReadAudio() {
                     params_.GetBytesPerBuffer(),
                     1.0);
 
+  // Need to account for time spent here due to renderer side mixing as well as

[miu, 2013/01/15 23:28:35]

You'll want to do almost exactly what's in
content/browser/renderer_host/media/web_contents_video_capture_device.cc, lines
888 through 908.  I went through a few iterations of this scheduling problem,
and I believe what's true for video is true for audio here.  In particular:

1. The goal is to target regular intervals of time.  Missed tasks shouldn't
recover by immediately posting a task with zero delay.  Instead, just schedule
for the next one to take place when it would have normally occurred.  This
should be better for the downstream code to keep audio and video in-sync.

2. Accounts for clock skew and major system time changes.

[justinlin, 2013/01/15 23:52:45]

The problem is there isn't a mechanism to skip ahead like you could can when
capturing snapshots. You have to read all the frames here, so if we get behind,
we have to catch up by scheduling the next callback sooner. This could
degenerate (I think that was Dale's concern), so in that case we just schedule
it at the regular time, but video/audio will end up slowing down, but everything
would probably be already pretty slow in that case.

[miu, 2013/01/16 03:43:03]

Okay.  I guess it doesn't matter either way, then.  I'm fine with the way you've
got it here.

BTW--Now you got me thinking of a new, killer feature for Chrome: A way to
playback all media faster simply by pulling audio at a faster rate.  ;-)  I
don't know about you, but I'd love to watch Youtube videos at 115-120% of normal
speed.  I used to do this with a homebrew DVR I put together, and watched so
much more TV in so much less time.

[justinlin, 2013/01/16 20:15:23]

Yea, cool idea :).

+  // the imprecision of PostDelayedTask.
+  next_read_time_ += buffer_duration_ms_;
+  base::TimeDelta delay = next_read_time_ - base::Time::Now();
+  if (delay < base::TimeDelta()) {
+    // Reset the next read time if we end up getting too far behind. We'll just
+    // slow down playback to avoid using up all the CPU.
+    delay = base::TimeDelta();
+    next_read_time_ = base::Time::Now();
+  }
+
   message_loop_->PostDelayedTask(FROM_HERE,
                                  on_more_data_cb_.callback(),
-                                 buffer_duration_ms_);
+                                 delay);
 }
 
 void VirtualAudioInputStream::Close() {