User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20130513 Firefox/23.0 Build ID: 20130513031057 Steps to reproduce: Tried to test a ROM inside gameboy-online. Actual results: Audio slowly overbuffered up to two seconds of lag. Expected results: Not have overbuffered into the audibly laggy range.

Do you have a ROM sample to test?

I'll update the url to one with pre-loaded, although please keep this internal (Not public).

This is definitely an issue for the user and not just lag. Firefox continues playing audio well after the window is closed, so a website could trash a user via this issue.

Albeit, the issue of possible websites exploiting overbuffering was present with moz-audio, but it had to be forced by web developer, and was not done by the browser itself glitching.

Removed URL as I updated the source for it so it uses moz audio over web audio. I'll need to roll out a custom page that uses the older audio code with a simple audio test.

So yeah, firefox, despite dropping samples, does NOT drop the request that was "missed" and does double requests after the lag spike. This seems responsible for firefox overbuffering. Firefox must cancel a scheduled request at some point.

To better explain the last commit, firefox tries to buffer for even times it could not buffer, so if it could not buffer for 20 ms, it buffers 40 ms for the next 20 ms interval. Firefox does not drop a so called buffer event to bring it back to normal buffering.

Maybe related to Bug 448534.

Do we have something tracking this?

What do you mean by overbuffering? Is there a test case?

What I mean is that Firefox will continue to request samples for a past time audio period that played with gapped audio due to lag. Hence it never drops a request for something that already "played" but by silence from lag. Firefox buffers to infinity with this bug if the web page continues playing with lag hiccups occasionally.

http://grantgalitz.org/sine_wave_testcase/ is a version of http://grantgalitz.org/sine_wave/ but only checks for web audio and doesn't try any other API. This way you can be sure it's web audio.

Actually that's a bad example, I need to make something interactive to test. A button based one probably.

(In reply to Kevin Brosnan [:kbrosnan] from comment #9) > Do we have something tracking this? Ehsan is the best person to respond to the issue directly which I see he has already done after this comment. I'm removing my name from the need info list unless there was something else you needed?

(In reply to Grant Galitz from comment #12) > http://grantgalitz.org/sine_wave_testcase/ is a version of > http://grantgalitz.org/sine_wave/ but only checks for web audio and doesn't > try any other API. This way you can be sure it's web audio. FWIW both of these URLs seem to belong to an expired domain name.

Do you still see this? We fixed a related problem a week or so ago.

Still bad. I altered two lines of my xaudiojs lib for my IodineGBA emulator to use web audio over moz audio and web audio ran into 2 seconds of audio lag. Switching tabs didn't kill the 2 second lag until it ran out either... that's how I know it's a moz bug (The emulator stops genning audio when the tab is hidden, and our internal buffer for the audio lib in the script is much shorter than 2 seconds...).

*flipped lines 133 and 137 inside https://github.com/grantgalitz/XAudioJS/blob/master/XAudioServer.js to use web audio over moz audio.

I stopped using grantgalitz.org, if I forgot some bugs with that domain in it, it can be removed.

Seems it got fixed in nightly. Nightly is consistently buffering audio to 500 ms though, which is still unacceptable for games that require synchronization between video/audio/input

Grant did you file a bug for your previous comment?

Not yet. Will have to make an easy to discern audibly test so others can see the keyboard input to audio output latency. I can tell it easily with my own projects, but they are not bugzilla style reduced one page + few lines of js reduced.