783052 - nsBufferedAudioStream::Init fails intermittently

Status: NEW

(Core :: Audio/Video: Playback, defect, P3)

Description

[(no longer active)]

I have a game demo which calls mozSetup on an HTML audio element in order to play audio from a buffer, and I have seen that on Windows, sometimes the mozSetup call fails with NS_ERROR_FAILURE.  I debugged this a bit and it happens because nsBufferedAudioStream::Init returns NS_ERROR_FAILURE, and the failure propagates to MozSetup.  This only happens once every 10-20 calls, but it causes js to see an unhandled exception and would abort the game.  This could also happen in any other games which use the Moz Audio Data API.

I can provide the test case to whoever wants to debug this further.

Comment 1

[Matthew Gregan [:kinetik]]

How many audio elements are you calling mozSetup on at once?  There's an internal limit of 32 active audio streams at the moment.

Comment 2

[(no longer active)]

(In reply to comment #1)
> How many audio elements are you calling mozSetup on at once?  There's an
> internal limit of 32 active audio streams at the moment.

If I'm counting the number correctly in the code, there should only be 27 elements.  And the bug happens even when calling mozSetup on a single audio element.

Comment 3

[Matthew Gregan [:kinetik]]

Okay, sounds like something else.  If you can set me up with the testcase, I'll take a look.

Comment 4

[Matthew Gregan [:kinetik]]

This only affects the cubeb backend; setting media.use_cubeb=false (to switch to the old audio backend) seems to work fine.  Waiting on a debug build to finish so I can investigate.

Comment 5

[Matthew Gregan [:kinetik]]

I haven't had a lot of time to look at this yet (sorry), but at least one of issues issues is that we are hitting the 32 stream limit (https://github.com/kinetiknz/cubeb/blob/master/src/cubeb_winmm.c#L327) on the testcase.

If you're not expecting 32 playing media elements at once, it's likely that the extras are hanging around until the GC runs.  If you know precisely when you're finished with a given audio element, setting its src property to null will immediately free the underlying OS audio stream.

The reason we have the 32 stream limit is documented in bug 742154.  It's possible (likely, even) that there's a bug in cubeb that causes this (especially as we didn't hit this with the old backend, but the old backend used threading much less aggressively), but I haven't been to find it yet.

I'm working on a general fix to this stream limit in bug 782507, by adding lightweight audio streams that are mixed in software and share a single OS stream for playback.

Comment 6

[(no longer active)]

(In reply to comment #5)
> I haven't had a lot of time to look at this yet (sorry), but at least one of
> issues issues is that we are hitting the 32 stream limit
> (https://github.com/kinetiknz/cubeb/blob/master/src/cubeb_winmm.c#L327) on the
> testcase.
> 
> If you're not expecting 32 playing media elements at once, it's likely that the
> extras are hanging around until the GC runs.  If you know precisely when you're
> finished with a given audio element, setting its src property to null will
> immediately free the underlying OS audio stream.

Hmm, so the Emscripten support cannot impose a maximum number limit, and it's totally possible that there are games out there which require more than 32 streams of audio...

> The reason we have the 32 stream limit is documented in bug 742154.  It's
> possible (likely, even) that there's a bug in cubeb that causes this
> (especially as we didn't hit this with the old backend, but the old backend
> used threading much less aggressively), but I haven't been to find it yet.
> 
> I'm working on a general fix to this stream limit in bug 782507, by adding
> lightweight audio streams that are mixed in software and share a single OS
> stream for playback.

OK, should we add a dependency on that bug here?  Also, do you have any estimates on when we can expect that bug to get fixed?

Thanks!

Comment 7

[Matthew Gregan [:kinetik]]

(In reply to Ehsan Akhgari [:ehsan] from comment #6)
> OK, should we add a dependency on that bug here?  Also, do you have any
> estimates on when we can expect that bug to get fixed?

Hopefully late next week or so.  I've added a dep.

Comment 8

[(no longer active)]

(In reply to comment #7)
> (In reply to Ehsan Akhgari [:ehsan] from comment #6)
> > OK, should we add a dependency on that bug here?  Also, do you have any
> > estimates on when we can expect that bug to get fixed?
> 
> Hopefully late next week or so.  I've added a dep.

That's great!

Comment 9

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Any movement here or on bug 782507 (lightweight streams)?