Do not wait for the synchronization in AudioSyncReader

content/browser/renderer_host/media/audio_sync_reader.cc

Index: content/browser/renderer_host/media/audio_sync_reader.cc
diff --git a/content/browser/renderer_host/media/audio_sync_reader.cc b/content/browser/renderer_host/media/audio_sync_reader.cc
index e6657ef74ca827455663b6a4862b71cfe19debb9..0f09fc138aeed7ca353af478fdf8ddc62238e82d 100644
--- a/content/browser/renderer_host/media/audio_sync_reader.cc
+++ b/content/browser/renderer_host/media/audio_sync_reader.cc
@@ -121,9 +121,7 @@ bool AudioSyncReader::PrepareForeignSocket(
 }
 
 bool AudioSyncReader::WaitUntilDataIsReady() {
-  base::TimeDelta timeout = maximum_wait_time_;
   const base::TimeTicks start_time = base::TimeTicks::Now();
-  const base::TimeTicks finish_time = start_time + timeout;
 
   // Check if data is ready and if not, wait a reasonable amount of time for it.
   //
@@ -131,33 +129,26 @@ bool AudioSyncReader::WaitUntilDataIsReady() {
   // and one here.  Every time a buffer is requested via UpdatePendingBytes(),
   // |buffer_index_| is incremented.  Subsequently every time the renderer has a
   // buffer ready it increments its counter and sends the counter value over the
-  // SyncSocket.  Data is ready when |buffer_index_| matches the counter value
-  // received from the renderer.
+  // SyncSocket.  Data is ready when |socket_| receive a counter value from
+  // the renderer.
   //
-  // The counter values may temporarily become out of sync if the renderer is
+  // The counter values can become out of sync if the renderer is
   // unable to deliver audio fast enough.  It's assumed that the renderer will
-  // catch up at some point, which means discarding counter values read from the
-  // SyncSocket which don't match our current buffer index.
-  size_t bytes_received = 0;
+  // automatically catch up at some point, and the browser should not wait for
+  // the synchronization since it needs to feed the received audio data to
+  // hardware ASAP.
   uint32 renderer_buffer_index = 0;
-  while (timeout.InMicroseconds() > 0) {

[no longer working on chromium, 2014/10/16 20:27:56]

Dale, besides the buffer size issue, I think we still have concern on these
code, is it the right thing to do to wait for the index synchronization even
though the browser has got data to proceed?
If you think it is, please explain why should we wait instead of passing the
data to the browser?

[DaleCurtis, 2014/10/16 21:14:14]

I don't understand what you're asking. The loop breaks once the right index is
received. If we don't drain the sync socket and the renderer is behind by more
than one buffer, we will never get the right index again.

-    bytes_received = socket_->ReceiveWithTimeout(
-        &renderer_buffer_index, sizeof(renderer_buffer_index), timeout);
-    if (bytes_received != sizeof(renderer_buffer_index)) {
-      bytes_received = 0;
-      break;
-    }
-
-    if (renderer_buffer_index == buffer_index_)
-      break;
-
-    // Reduce the timeout value as receives succeed, but aren't the right index.
-    timeout = finish_time - base::TimeTicks::Now();
+  size_t bytes_received = socket_->ReceiveWithTimeout(
+      &renderer_buffer_index, sizeof(renderer_buffer_index),
+      maximum_wait_time_);
+  if (bytes_received != sizeof(renderer_buffer_index)) {
+    // Set |bytes_received| to 0 to indicate it is a timeout.
+    bytes_received = 0;
   }
 
   // Receive timed out or another error occurred.  Receive can timeout if the
   // renderer is unable to deliver audio data within the allotted time.
-  if (!bytes_received || renderer_buffer_index != buffer_index_) {
+  if (!bytes_received) {
     DVLOG(2) << "AudioSyncReader::WaitUntilDataIsReady() timed out.";
 
     base::TimeDelta time_since_start = base::TimeTicks::Now() - start_time;