Since the introduction of PushSource, there are two buffering layers in the

browser process, the hardware buffer used in AudioOutputStream and
transportation buffer in PushSource. Together with the latency in the IPC
audio layer we have a serious AV sync problem.

To compensate the delay and latency introduced by these three factors
two parameters are added in RequestAudioPacket message that include
the buffer fill level and timestamp of the request. These two parameters
are used to determine the playback delay to be used by the audio
renderer to update the pipeline with the time delta.

So we have three parameters we need to care about:
1. Hardware buffer in AudioOutputStream
2. Buffered data in PushSource
3. IPC latency

We have accurate values for 2 and 3 but not 1. We currently don't have the
API in AudioOutputStream to query the remaining buffer in the hardware
buffer. But usually there is a large amount of data in it, e.g. on Windows
400ms worth of data. Since we now detached the hardware buffer request of
OnMoreData() from the actual packet request of IPC (by the introduction of
PushSource), it is really critical to know the buffer level in the hardware.
I made a guess of this buffer level by using the amount of last buffer copy.

Review URL: http://codereview.chromium.org/122020

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18536 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 24 insertions, 1 deletions

diff --git a/chrome/browser/renderer_host/audio_renderer_host.cc b/chrome/browser/renderer_host/audio_renderer_host.cc
index f07d8e5..1d2bf07 100644
--- a/chrome/browser/renderer_host/audio_renderer_host.cc
+++ b/chrome/browser/renderer_host/audio_renderer_host.cc
@@ -216,6 +216,7 @@ size_t AudioRendererHost::IPCAudioSource::OnMoreData(AudioOutputStream* stream,
   size_t size = push_source_.OnMoreData(stream, dest, max_size);
   {
     AutoLock auto_lock(lock_);
+    last_copied_bytes_ = size;
     SubmitPacketRequest(&auto_lock);
   }
   return size;
@@ -239,6 +240,11 @@ void AudioRendererHost::IPCAudioSource::NotifyPacketReady(
   {
     AutoLock auto_lock(lock_);
     outstanding_request_ = false;
+#ifdef IPC_MESSAGE_LOG_ENABLED
+    if (IPC::Logging::current()->Enabled()) {
+      RecordRoundTripLatency(base::Time::Now() - outstanding_request_time_);
+    }
+#endif
     // If reported size is greater than capacity of the shared memory, we have
     // an error.
     if (decoded_packet_size <= decoded_packet_size_) {
@@ -272,7 +278,24 @@ void AudioRendererHost::IPCAudioSource::SubmitPacketRequest_Locked() {
       (push_source_.UnProcessedBytes() + decoded_packet_size_ <=
        buffer_capacity_)) {
     outstanding_request_ = true;
-    host_->Send(new ViewMsg_RequestAudioPacket(route_id_, stream_id_));
+    outstanding_request_time_ = base::Time::Now();
+
+    // This variable keeps track of the total amount of bytes buffered for
+    // the associated AudioOutputStream. This value should consist of bytes
+    // buffered in AudioOutputStream and those kept inside |push_source_|.
+    // TODO(hclam): since we have no information about the amount of buffered
+    // bytes in the hardware buffer in AudioOutputStream, we make our best
+    // guess by using the amount of the last copy. This should be a good guess
+    // for Windows since it does double buffering but we shold change this
+    // when AudioOutputStream has the API to query remaining buffer.
+    size_t buffered_bytes = last_copied_bytes_ +
+                            push_source_.UnProcessedBytes();
+    host_->Send(
+        new ViewMsg_RequestAudioPacket(
+            route_id_,
+            stream_id_,
+            buffered_bytes,
+            outstanding_request_time_.ToInternalValue()));
   }
 }