647732 - mozSetup fails after allocating a certain number of Audio objects

Status: RESOLVED WONTFIX

(Core :: Audio/Video, defect)

Description

[Hasen il Judy]

User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0) Gecko/20100101 Firefox/4.0

I'm experimenting with the Audio API in Firefox 4 and trying to create a music keyboard kind of application.

The application creates a few Audio objects as soon as it loads; this is basically an initialization step. Each object is initialized like this:

  audio = new Audio()
  audio.mozSetup(1, 44100)

As I'm developing, I make lots of changes and have to refresh the page to see the effects of these changes.

After a few reloads, however, mozSetup will fail and thus the audio objects won't work anymore.

It's as if all audio "resources" have run out, and none of the unused ones are getting garbage collected.

I don't know a way around that without restarting the browser. No matter how many times I refresh, mozSetup keeps failing. So I restart firefox and mozSetup works again. 

At the time of this writing, a deployed version of my experimental application is available on http://oud.hasenj.org

While I was creating a small html page to demonstrate the problem, I found that sometimes just refreshing again works. I'm not sure what's causing that; maybe because I break after the first failed mozSetup? Not sure if that has anything to do with it.

Reproducible: Always

Steps to Reproduce:
1. Allocate a few audio objects in javascript and set them up with mozSetup, for example: `audio.mozSetup(1, 44100)`
2. Reload the page a few times
3. At some point, mozSetup on newly allocated objects will fail



I restart using an extension called "restartless restart".

I'm on Ubuntu 11.04 beta. I've experienced a few sound problems with youtube and other flash-based video players. This might be a bug in this beta version of Ubuntu itself for all I know. It would be good if people use the test case on Mac and Windows to confirm whether or not it's OS-specific.

Comment 1

[Hasen il Judy]

Attachment: Small test case

Comment 2

[Hasen il Judy]

Sorry, marked as security-sensitive by mistake.

Comment 3

[David Humphrey (:humph)]

I'm unable to reproduce on my machine (Mac 10.6, but very good hardware).  It is entirely possible that we aren't able to allocate a new stream, and it's resource starvation.  Hopefully someone else can reproduce.  CC'ing Yury, too.

What is the exact exception you get when it throws?

Comment 4

[Hasen il Judy]

The exception is:

[Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMHTMLAudioElement.mozSetup]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: https://bug647732.bugzilla.mozilla.org/attachment.cgi?id=524010 :: :: line 8" data: no]

I just noticed that many "applications" are created in the sound preferences window; sometimes they go away, sometimes they don't. There's a clear correlation between the number of such applications and failure of mozSetup.

Comment 5

[Hasen il Judy]

Attachment: Correlation between "Audio" objects in Firefox and sound applications in Ubuntu's sound preferences

A small screen video capture, around 50 seconds.

As I refresh the page, more applications are added the sound preferences window. At some point I get the exception.

Then, you can see the number of applications in Ubuntu's sound menu is getting smaller, indicating perhaps that old objects are getting garbage collected (either by firefox or by ubuntu) and then I refresh the page and it works.

Comment 6

[Yury Delendik (:yury)]

Was able to replicate on ubuntu 10.10. Found the record in the syslog: 

pulseaudio[1450]: sink-input.c: Failed to create sink input: too many inputs per sink.

Comment 7

[Yury Delendik (:yury)]

The limit of inputs per sink defined as:

#define PA_MAX_INPUTS_PER_SINK 32

Comment 8

[Matthew Gregan [:kinetik]]

I can reproduce this is I refresh the testcase quickly enough, but if I wait a few seconds between refreshes the old audio elements are GCed and the underlying audio streams are closed.

Out of curiosity, what's the use case for opening so many audio streams at once?

Comment 9

[Hasen il Judy]

The use case is a newbie experimenting with generating several audio streams at the same time.

I've now transitioned to using the audiodata library's AudioDataMixer, which while getting rid of this problem, produced another problem. (I'll try to submit a bug report about it here once I know more precisely where the problem lies).

https://github.com/notmasteryet/audiodata/issues/1

Comment 10

[u279076]

Based on comment 8, I think we can mark this NEW.

Comment 11

[Matthew Gregan [:kinetik]]

The Audio Data API was deprecated in bug 855570, which shipped in Firefox 23.  Developers should now be targeting the standardized Web Audio API instead, and filing bugs against it as necessary.  There's no point keeping the Audio Data API bugs open as we'll never fix them and will eventually remove the code.  Closing on that basis.