Web Audio ScriptProcessorNode Spontaneously Goes Silent

RESOLVED FIXED in mozilla29



6 years ago
4 years ago


(Reporter: grantgalitz, Assigned: padenot)


28 Branch
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




(1 attachment)

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.
Blocks: webaudio
Component: Untriaged → Web Audio
Product: Firefox → Core
(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.
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.
See https://github.com/grantgalitz/XAudioJS/blob/master/XAudioServer.js#L185 for the initializeWebAudio() function code referred to.
Ever confirmed: true
Summary: Web Audio API Spontaneously Goes Silent → Web Audio ScriptProcessorNode Spontaneously Goes Silent

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.
Priority: -- → P1
Assignee: nobody → paul
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.
Attachment #8347314 - Flags: review?(ehsan)
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
Attachment #8347314 - Flags: review?(ehsan) → review+
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla29
Blocks: 970083
See Also: → 1157137
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.
You need to log in before you can comment on or make changes to this bug.