Remove AudioBuffersState usage in Chromium

media/audio/audio_output_controller.cc

Index: media/audio/audio_output_controller.cc
diff --git a/media/audio/audio_output_controller.cc b/media/audio/audio_output_controller.cc
index 45d308db3effd64f12394570200c1f90b515ea4f..c793cd06f864fe55c382312dfe4f32e85f08d893 100644
--- a/media/audio/audio_output_controller.cc
+++ b/media/audio/audio_output_controller.cc
@@ -280,7 +280,7 @@ void AudioOutputController::DoReportError() {
 }
 
 int AudioOutputController::OnMoreData(AudioBus* dest,
-                                      AudioBuffersState buffers_state) {
+                                      int total_bytes_delay) {

[palmer, 2014/09/18 18:39:40]

void AudioSyncReader::UpdatePendingBytes(uint32 bytes)

int != uint32 in signedness and possibly even in width (ILP64).

(UpdatePendingBytes is correct to be defined as taking uint32; thus, change
|total_bytes_delay| to be uint32.)

[acolwell GONE FROM CHROMIUM, 2014/09/19 17:16:46]

Done.

   TRACE_EVENT0("audio", "AudioOutputController::OnMoreData");
 
   // Indicate that we haven't wedged (at least not indefinitely, WedgeCheck()
@@ -294,7 +294,7 @@ int AudioOutputController::OnMoreData(AudioBus* dest,
 
   const int frames = dest->frames();
   sync_reader_->UpdatePendingBytes(
-      buffers_state.total_bytes() + frames * params_.GetBytesPerFrame());
+      total_bytes_delay + frames * params_.GetBytesPerFrame());

[palmer, 2014/09/18 18:39:40]

I see this:

// media::AudioOutputController::SyncReader implementations.
void AudioSyncReader::UpdatePendingBytes(uint32 bytes) {
  // Zero out the entire output buffer to avoid stuttering/repeating-buffers
  // in the anomalous case if the renderer is unable to keep up with real-time.
  output_bus_->Zero();
  socket_->Send(&bytes, sizeof(bytes));
  ++buffer_index_;
}

But, after we send |bytes| on the socket, what does the receiver do with the
value? (I'm sorry, I am not familiar with the audio code, so I don't know
off-hand.) Can you show me how integer overflow doesn't matter for how the
receiver uses the value?

[acolwell GONE FROM CHROMIUM, 2014/09/19 17:16:46]

The receiver of this value is in AudioDeviceThread::Thread::Run(). The Receive()
call was actually using an int instead of a uint32, which I have fixed in the
latest patch. Thanks for being persistant on this point. :)

 
   if (will_monitor_audio_levels())
     power_monitor_.Scan(*dest, frames);