Fix VirtualAudioInputStream callback timing issues.

media/audio/virtual_audio_input_stream.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "media/audio/virtual_audio_input_stream.h"
 
 #include <algorithm>
 #include <utility>
 
 #include "base/bind.h"
@@ skipping 67 matching lines @@
 }
 
 bool VirtualAudioInputStream::Open() {
   memset(buffer_.get(), 0, params_.GetBytesPerBuffer());
   return true;
 }
 
 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,
                                              on_more_data_cb_.callback());
 }
 
 void VirtualAudioInputStream::Stop() {
   DCHECK(message_loop_->BelongsToCurrentThread());
   on_more_data_cb_.Cancel();
 }
@@ skipping 34 matching lines @@
   audio_bus_->ToInterleaved(params_.frames_per_buffer(),
                             params_.bits_per_sample() / 8,
                             buffer_.get());
 
   callback_->OnData(this,
                     buffer_.get(),
                     params_.GetBytesPerBuffer(),
                     params_.GetBytesPerBuffer(),
                     1.0);
 
+  // Need to account for time spent here due to renderer side mixing.
+  next_read_time_ += buffer_duration_ms_;
+  base::TimeDelta delay = next_read_time_ - base::Time::Now();
+  if (delay < base::TimeDelta())

[DaleCurtis, 2013/01/15 21:00:08]

I'd worry about drift over time here. Can you limit this calculation to the
delta between ReadAudio() calls? I.e. reset next_read_time_ based on
base::Time::Now() in each call.

[justinlin, 2013/01/15 22:36:21]

I tested this and actually the comment I left there isn't quite right.
PostDelayedTask actually contributes to the imprecision as well. I think a
combination of the time spent in audio conversions and the imprecision of
PostDelayedTask pushes it just over the edge to produce a pretty noticeable
framerate drop (i.e. the posttask delay ends up fluctuating between 8 and 9ms on
my machine if we do account for both things). Accounting for only the audio
conversions is not enough.

As for drift towards the delay getting shorter and shorter and eventually using
up all the cpu, how about we just reset the next read time in that case. We'll
get a video slow down but at least it won't end up spinning.

+    delay = base::TimeDelta();
+
   message_loop_->PostDelayedTask(FROM_HERE,
                                  on_more_data_cb_.callback(),
-                                 buffer_duration_ms_);
+                                 delay);
 }
 
 void VirtualAudioInputStream::Close() {
   DCHECK(message_loop_->BelongsToCurrentThread());
   if (callback_) {
     DCHECK(on_more_data_cb_.IsCancelled());
     callback_->OnClose(this);
     callback_ = NULL;
   }
   audio_manager_->ReleaseInputStream(this);
 }
 
 double VirtualAudioInputStream::GetMaxVolume() {
   return 1.0;
 }
 
 void VirtualAudioInputStream::SetVolume(double volume) {}
 
 double VirtualAudioInputStream::GetVolume() {
   return 1.0;
 }
 
 void VirtualAudioInputStream::SetAutomaticGainControl(bool enabled) {}
 
 bool VirtualAudioInputStream::GetAutomaticGainControl() {
   return false;
 }
 
 }  // namespace media