Grant Galitz Reporter
	Description • 11 years ago

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.

	Loic
	Comment 1 • 11 years ago

Do you have a ROM sample to test?

	Grant Galitz Reporter
	Comment 2 • 11 years ago

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

	Grant Galitz Reporter
	Comment 3 • 11 years ago

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.

	Grant Galitz Reporter
	Comment 4 • 11 years ago

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.

	Grant Galitz Reporter
	Comment 5 • 11 years ago

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.

	Grant Galitz Reporter
	Comment 6 • 11 years ago

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.

	Grant Galitz Reporter
	Comment 7 • 11 years ago

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.

	Liz Henry (:lizzard Please n-i to RyanVM, jcristau, or pascal)
	Comment 8 • 11 years ago

Maybe related to Bug 448534.

	Kevin Brosnan [Ex-Mozilla]
	Comment 9 • 11 years ago

Do we have something tracking this?

	(no longer active)
	Comment 10 • 11 years ago

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

	Grant Galitz Reporter
	Comment 11 • 11 years ago

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.

	Grant Galitz Reporter
	Comment 12 • 11 years ago

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.

	Grant Galitz Reporter
	Comment 13 • 11 years ago

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

	Martin Best (:mbest)
	Comment 14 • 11 years ago

(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?

	(no longer active)
	Comment 15 • 11 years ago

(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.

	Paul Adenot (:padenot)
	Comment 16 • 11 years ago

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

	Grant Galitz Reporter
	Comment 17 • 11 years 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...).

	Grant Galitz Reporter
	Comment 18 • 11 years ago

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

	Grant Galitz Reporter
	Comment 19 • 11 years ago

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

	Grant Galitz Reporter
	Comment 20 • 11 years ago

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

	Kevin Brosnan [Ex-Mozilla]
	Comment 21 • 11 years ago

Grant did you file a bug for your previous comment?

	Grant Galitz Reporter
	Comment 22 • 11 years ago

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.