Web Audio ScriptProcessorNode Spontaneously Goes Silent

RESOLVED FIXED in mozilla29



Web Audio
4 years ago
3 years ago


(Reporter: Grant Galitz, Assigned: padenot)


28 Branch
Mac OS X
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




(1 attachment)



4 years ago
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: 779297
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.

Comment 3

4 years ago
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.

Comment 4

4 years ago
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.

Comment 5

4 years ago
Does this also happen on Firefox 25?

Comment 6

4 years ago
(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

Comment 7

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

Comment 8

4 years ago
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.

Comment 10

4 years ago
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.

Comment 11

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

Comment 12

4 years ago
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.

Comment 13

4 years ago
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.

Comment 15

4 years ago
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

Comment 16

4 years ago

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

Comment 17

4 years ago
Created attachment 8347314 [details] [diff] [review]
Make sure the latency does not grow up in ScriptProcessorNode. r=

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 18

4 years ago
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+
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla29

Comment 21

3 years ago
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.