There is a racing between SyncSocket::Receive in audio_thread_ and SyncSocket::Close in renderer ...

content/renderer/media/audio_device.cc

Index: content/renderer/media/audio_device.cc
===================================================================
--- content/renderer/media/audio_device.cc	(revision 111890)
+++ content/renderer/media/audio_device.cc	(working copy)
@@ -25,7 +25,8 @@
       callback_(callback),
       audio_delay_milliseconds_(0),
       volume_(1.0),
-      stream_id_(0) {
+      stream_id_(0),
+      audio_event_(true, false) {

[enal1, 2011/11/29 16:14:48]

Can you please explain what exactly arguments to event constructor mean...

[tommi (sloooow) - chröme, 2011/11/29 16:41:53]

I think it's ok to set |manual_reset| to false in this case (first argument).

   filter_ = RenderThreadImpl::current()->audio_message_filter();
   audio_data_.reserve(channels);
   for (int i = 0; i < channels; ++i) {
@@ -72,7 +73,7 @@
   // function call.
   if (completion.TimedWait(kMaxTimeOut)) {
     if (audio_thread_.get()) {
-      socket_->Close();
+      audio_event_.Signal();
       audio_thread_->Join();
       audio_thread_.reset(NULL);
     }
@@ -185,6 +186,7 @@
   // Allow the client to pre-populate the buffer.
   FireRenderCallback();
 
+  audio_event_.Reset();

[tommi (sloooow) - chröme, 2011/11/29 16:41:53]

if you set manual_reset to false, you don't have to do this step.

   audio_thread_.reset(
       new base::DelegateSimpleThread(this, "renderer_audio_thread"));
   audio_thread_->Start();
@@ -210,7 +212,8 @@
   const int samples_per_ms = static_cast<int>(sample_rate_) / 1000;
   const int bytes_per_ms = channels_ * (bits_per_sample_ / 8) * samples_per_ms;
 
-  while ((sizeof(pending_data) == socket_->Receive(&pending_data,
+  while (!audio_event_.IsSignaled() &&

[enal1, 2011/11/29 16:14:48]

I don't fully understand how event helps in a case when thread is blocked on
socket wait. I.e. suggested solution works if there is consistent stream of data
coming in, but not for case when there is no data...

[tommi (sloooow) - chröme, 2011/11/29 16:41:53]

good point!  Is there a way to read from the socket asynchronously?

[no longer working on chromium, 2011/11/30 17:02:55]

Really good question. No, event does not help at all when the socket is waiting
for receiving, but the current solution, which calls socket_.Close() does not
fix the problem either, the Close() can only jumps in after socket finishes
receiving.

+         (sizeof(pending_data) == socket_->Receive(&pending_data,
                                                    sizeof(pending_data))) &&
          (pending_data >= 0)) {
     // Convert the number of pending bytes in the render buffer
@@ -218,6 +221,8 @@
     audio_delay_milliseconds_ = pending_data / bytes_per_ms;
     FireRenderCallback();
   }
+
+  socket_->Close();
 }
 
 void AudioDevice::FireRenderCallback() {