Closed Bug 742154 Opened 12 years ago Closed 12 years ago

Work around media crashtest hangs in cubeb_winmm.c

Categories

(Core :: Audio/Video, defect)

All
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla14

People

(Reporter: kinetik, Assigned: kinetik)

References

(Depends on 1 open bug)

Details

Attachments

(1 file)

The winmm backend hangs during shutdown after running the media crashtests.  Despite spending a significant amount of time debugging this, I don't yet understand what the cause of this problem is.  The symptoms are as follows:

Browser hangs during shutdown after running media crashtests.  Main thread is waiting for decode related threads to terminate.  The decoders are all waiting on their audio threads to terminate.  The audio threads are blocked in cubeb_stream_destroy waiting for the enqueued buffer count to reach zero.  The buffers should become free either by completing playback, or by waveOutReset returning the buffers.  cubeb_buffer_callback is never called to release these buffers, and the dwFlags of the buffers remain WHDR_PREPARED | WHDR_INQUEUE.  In all observed cases, the enqueued buffers are the original NBUFS queued in cubeb_stream_init, and have not been returned via cubeb_buffer_callback even once.

An alternate situation appears where the audio threads are blocked in nsBufferedAudioStream::Write waiting on more space in mBuffer after starting the stream.  As above, the original NBUFS are queued and have never been returned via cubeb_buffer_callback.  cubeb_stream_start has been successfully called on these streams, 

This bug also appears in alternate versions of the code using the CALLBACK_EVENT and CALLBACK_THREAD mechanisms of waveOutOpen.  It has also been observed in a version where the buffers are not submitted for playback until cubeb_stream_start is called (after waveOutRestart succeeds).

To work around this, a limit of 32 active streams was chosen.  This limit is somewhat arbitrary, but it should be noted that a limit of 64 active streams still resulted in this deadlock-type situation occuring.
Attached patch patch v0Splinter Review
- Re-enables cubeb (where's it's built, which is only Windows for now).
- Adds an error state to nsBufferedAudioStream and associated handling.  Allows cubeb's callback to signal that a stream is broken.
- Import latest cubeb changes for cubeb_winmm.c and cubeb.h:
  - Add CUBEB_STREAM_MAX workaround discussed in this bug. :-(
  - Remove unnecessary unprepare/prepare in drain path.
  - Handle various waveOut API errors rather than asserting.
  - Fix bytes_per_frame for CUBEB_SAMPLE_S16LE.
  - Tidy up work loop in cubeb_buffer_thread.
Attachment #612082 - Flags: review?(cpearce)
Comment on attachment 612082 [details] [diff] [review]
patch v0

Review of attachment 612082 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good, but 8 lines of context in patches to make reviewing patches easier please!

::: media/libcubeb/src/cubeb_winmm.c
@@ +125,2 @@
>    if (got < 0) {
>      /* XXX handle this case */

Maybe you should at least leave the critical section in this case.
Attachment #612082 - Flags: review?(cpearce) → review+
https://hg.mozilla.org/mozilla-central/rev/0e390be0b88f
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Depends on: 747793
Depends on: 793024
Depends on: 802037
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: