User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:28.0) Gecko/20100101 Firefox/28.0 (Beta/Release) Build ID: 20131029030201 Steps to reproduce: 1) Used IodineGBA 2) Enabled audio Actual results: Audio stream was correctly playing until a random resize of the browser window threw off Firefox's web audio API (Super long firefox process stall). I inspected the XAudioJS I coded responsible for pushing audio out and confirmed the web audio API was still firing callbacks correctly and our ring buffer in JS was being drained like it should. Might be a bounds check issue in firefox caused by the whole internal buffer inside firefox draining from the long pause? This is *hard* to reproduce on my machine... It requires extensive pressure testing to create a long pause and it's not always successful at glitching. Expected results: Audio to not randomly go silent.

(In reply to Grant Galitz from comment #0) > Steps to reproduce: > 1) Used IodineGBA > 2) Enabled audio Could you please add some details here ?

And is ScriptProcessorNode involved? Might be similar to bug 899135 comment 15 and 17.

From the looks of it, it might be a Mac OS X 10.9 bug. I reproduced it by connecting my MBP to a TV as a second monitor with the audio pointing mini display port. Seems like an OS bug as audio system wide goes silent. It's still not 100% reproducible, but I'm managing to reproduce it enough now. ScriptProcessorNode and moz audio, both have this issue. About using IodineGBA, I mentioned it as it throws firefox under heavy load, to give the possibility it might be a full load bug, as well as being the personal web app project I was working on when it happened.

Putting firefox into fullscreen then taking it out of fullscreen (as in the "fullscreen" widget on the top right of the firefox window) seems to cause this.

Does this also happen on Firefox 25?

(In reply to :Ehsan Akhgari (needinfo? me!) from comment #5) > Does this also happen on Firefox 25? only on non-mac computers, as we make non-mac firefox use web audio first

Reason for that OS sniff is moz audio data api legacy bug workarounds

I reproduced this on Firefox 26, Windows XP, single core P4 2.2 Ghz, no HWA. With http://gbagames.github.io/gamecenter/launcher.html#pokemonruby running at ~30% there was no sound. When I flipped about:config?filter=media.webaudio.enabled to false, then reloaded the page, sound played.

Anyhow, we're using https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html#ScriptProcessorNode-section inside https://github.com/grantgalitz/XAudioJS/blob/master/XAudioServer.js#L228

Should note latency on firefox's part is very unstable on my machine, I get 100 to 500 ms or more of audio lag with pops and click even at 100% speed.

And we're providing a continuous stream of audio to destination, the chain is literally that node to output, with no in-between chain...

So it turns out Mardeg's problem might be from a bug that was fixed in newer firefox versions (scriptprocessornode never working). I forced moz audio usage over web audio whenever moz audio is found to mitigate this firefox bug. See Still doesn't explain the random audio silence on my machine. I was able to "restart" the audio stream by calling Mixer.audio.initializeWebAudio() in console, which tells me the web audio api in firefox has a corrupted audio graph.

Maybe Firefox is dropping that source when cpu load inside javascript approaches 100%, when it shouldn't. If I can recall, browsers are allowed to stop certain parts of the graph is load gets too high. This is wrong in this case, as it's a simple copy out operation.

Derp, I forgot to add https://github.com/grantgalitz/XAudioJS/commit/2ebb380a9788998f8db92bea96df0e27da615549 after the "see"

See https://github.com/grantgalitz/XAudioJS/blob/master/XAudioServer.js#L185 for the initializeWebAudio() function code referred to.

http://i.imgur.com/Hi6MPed.png Even when it goes "silent" the callback is being called. Those numbers in that image show the callback is draining our JavaScript held ring buffer.

This is a bit tricky, but I updated the comment. This makes things better, during my testing. It successfuly "resets" the node when stuff has happened that made it silent, because mLatency grew beyond control and failed to go down. Also, I should mention that I could repro by blocking/delaying the main thread artificially by spamming the event loop from the content.

Comment on attachment 8347314 [details] [diff] [review] Make sure the latency does not grow up in ScriptProcessorNode. r= Review of attachment 8347314 [details] [diff] [review]: ----------------------------------------------------------------- ::: content/media/webaudio/ScriptProcessorNode.cpp @@ +114,5 @@ > mLatency += latency - bufferDuration; > mLastEventTime = now; > + if (mLatency > MAX_LATENCY_S || > + (mDroppingBuffers && mLatency > 0.0 && > + abs(latency - bufferDuration) < bufferDuration)) { Nit: fabs

https://hg.mozilla.org/integration/mozilla-inbound/rev/9c55ce329853 https://hg.mozilla.org/integration/mozilla-inbound/rev/34dba94651cc (failed to qref the review comments on the first push).

https://hg.mozilla.org/mozilla-central/rev/9c55ce329853 https://hg.mozilla.org/mozilla-central/rev/34dba94651cc

Never was resolved. Also adding a test url where you pick a game to load into a JavaScript gba emulator. The audio is extremely laggy and has been proven to be within Firefox and not the js side.