1152863 - Unstable ScriptProcessor based WebAudio playback

Status: RESOLVED WORKSFORME

(Core :: Web Audio, defect, P2)

Description

[tinyrsid]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:37.0) Gecko/20100101 Firefox/37.0
Build ID: 20150402191859

Steps to reproduce:

I've programmed various WebAudio based chiptune players / emulators, e.g. http://www.wothke.ch/spectreZX/ (The JavaScript code is generated using Emscripten.)






Actual results:

Since the time I did my first player (it was Firefox 26 back then) I made the unfortunate observation, that the page/music plays very reliably using Google Chrome but the same page played in Firefox leads to unpredictable browser crashes. Unfortunately the situation does not seem to have improved much up until now (Firefox 37). 

As compared with Chrome, the page already loads quite sluggishly and sometimes Firefox hangs before the music even starts. In most cases the music playback starts but then Firefox just crashes somewhere in the middle of the playback (however sometimes it plays for hours with no problem at all..)

I have given up trying to debug in Firefox because invokation of the developer tools seems to be the surest thing to crash Firefox :-( (the abysmally bad development tools stability certainly deserves a separate bug report.. )


Expected results:

Obviously Firefox should not crash but intstead properly play back the music (like Chrome does).. 

since it doesn't always crash (or not right away) the root cause of this issue may be hard to pin down..

Comment 1

[tinyrsid]

Attachment: zipped version of my respective web page

The zip archive contains the complete folder of my respective web page. Just copy its content into the htdocs folder of your webserver and you are ready to test it locally.

Comment 2

[tinyrsid]

Today I again witnessed the effect but I made an additional observation: Again the WebAudio based music playback suddenly stopped for no good reason. However the frequency spectrum visualization apparently still ran, i.e. for 1-2 secs after the music had already stopped the spectrum was still showing some very slow wave like pattern. Then the spectrum visualization just froze - with remainders of the "wave like pattern" still visible (which already is odd because the spectrum should be completely empty while there is no music). 

But then when I minimized the respective Firefox window the WebAudio music resumed playing! (i.e. the page was not actually dead but for some reason the events to request new sample data no longer fired..) However as soon as I "restored" the window to its former position the music almost immediately stopped again (with the same effect on the visualization described above). I repeated the steps multiple times: "restore window" -> music playback freezes, "minimize window" -> music playback resumes. I think it was when I finally switched the visible browser tab (to see if that might also resume the plackback) that the situation further deteriorated and I no longer managed to resume the music playback.. (also the "minimize window" trick no longer worked)

Comment 3

[tinyrsid]

Another observation: It looks as if the problem were triggered by a temporarry CPU "overload" situation, e.g. start of another program causes CPU load to reach 100% before falling back to normal. It seems that *some part* of the WebAudio pipeline in that moment detects that it is not receiving sample data quickly enough and instead of sitting out the temporarry situation decides to completely stop processing..

However I checked and the 'onaudioprocess' event keeps still getting fired, i.e. my ScriptProcessor keeps generating sample data while it is just no longer played back by Firefox's WebAudio impl.

Comment 4

[tinyrsid]

PS: I am meanwhile using version FF 38.0.5 and the problem still persists. But I would meanwhile change the phrasing of my initial post: I'm no longer witnessing *crashes* of the complete browser but as I illustrate above it seems to be a partial shutdown within the WebAudio related processing.

Comment 5

[tinyrsid]

Actually it might be that the problem is actually triggered by my use of the AnalyzerNode's spectrum data within my "animation frame" logic: In my original rendering function I immediately called Window.requestAnimationFrame() - i.e. setting up the next animation frame even before I had handled the current one. I don't know if that might lead to the concurrent execution of a second rendering call while the previous one is still in progress. I recently moved that call to the very end of my rendering function and since I made that change I have not yet observed the problem again..

I have not performed much testing yet and I therefore cannot be 100% sure that my change always fixes the problem.. but I have a hunch that the problem might be caused by some AnalyzerNode related concurrency issue.

Comment 6

[tinyrsid]

update: today I again witnessed the problem (i.e. it isn't only my previous use of Window.requestAnimationFrame - eventhough it might be a way to force the appearance of the effect). It was with one of my "slower" players: http://www.wothke.ch/webvgm/ and in a "high CPU load" situation (I had been compiling in some "DOS prompt") - the problem persisted long after the compile had completed. Again the "progress bar" that I am using on the page kept advancing - indicating that the sample generating logic was still running.. but there was no audio nor any AnalyzerNode frequency data any more. Then after about one minute of silence the audio playback suddenly kicked back in...!?

Comment 7

[tinyrsid]

Attachment: WebAudio AnalyzerNode frequency spectrum data output while music has long stopped..

At the point when I took this screenshot, the WebAudio playback had already stopped for several seconds. By "stopped" I mean that there was no longer any music to be heard - eventhough it seems that my audio sample generation callback still kept getting called..

The AnalyzerNode showed the respective, almost static pattern all the while there was no longer any audio output.. there were small changes in the delivered "frequency spectrum data", i.e. the displayed "curve" very slowly "collapsed" to the ground..

Comment 8

[tinyrsid]

I just reproduced the problem on Windows7 (I also added a screenshot to illustrate the effect): To put some load on my CPU I started several video conversion processes (VirtualDub) in the background.. unfortunately this approach did not relyably trigger the problem - still after a while the problem did occur.

So this is not just some legacy WinXP issue - but it occurs also on a more recent OS (I consequently updated the ticket to Win7).

When I observed the problem today it was of the "milder" variety, i.e. the playback stopped only for some seconds and then resumed.. due to the limited amount of Win7 testing I cannot say if the problem always "recovers" more quickly on Win7 - but the problem also affects Win7.


In any case: I first reported this problem in April 2015 and until now the feedback I got from the Mozilla side is exactly ZERO! It seems that you just don't care about FF bugs.. I better stop wasting my time here and reinstall Chrome :-(

Comment 9

[Maire Reavy [:mreavy]]

My most sincere apologies for our delay in commenting.  We've made major perf improvements over the last several releases.  I can't repro this problem in Nightly even when running a Firefox build using 100% of all threads (on a Win 7 machine).  Can you re-test and let us know if this problem is resolved for you or not?  Thanks.

Comment 10

[tinyrsid]

Thank you for your feedback. I just upgraded to FF 41.0.2 and I've not been able to reproduce this issue (on my WinXP machine) so far. I think this has been fixed somewhere between version 39 and 41 - looks good now.

Comment 11

[Maire Reavy [:mreavy]]

Thanks for re-testing. I'm marking this as "WORKSFORME".  If you run into any new problems, please feel to reach out to me in #media on irc and file a new bug.  You should get a response on any new bug in less than a week. If you need an immediate response, please needinfo me, and I'll get back to you ASAP (typically in less than one business day).