Status

()

defect
RESOLVED WORKSFORME
6 years ago
4 years ago

People

(Reporter: grantgalitz, Unassigned)

Tracking

(Blocks 1 bug)

23 Branch
x86
macOS
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [games])

Reporter

Description

6 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.
Reporter

Updated

6 years ago
Component: Untriaged → Webapp Runtime
Component: Webapp Runtime → Untriaged

Comment 1

6 years ago
Do you have a ROM sample to test?
Flags: needinfo?(grantgalitz)
Reporter

Comment 2

6 years ago
I'll update the url to one with pre-loaded, although please keep this internal (Not public).
Flags: needinfo?(grantgalitz)
Reporter

Comment 3

6 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.
Reporter

Comment 4

6 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.
Reporter

Comment 5

6 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.
Reporter

Comment 6

6 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.
Reporter

Comment 7

6 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.
Component: Untriaged → Video/Audio
Product: Firefox → Core

Updated

6 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Do we have something tracking this?
Flags: needinfo?(mbest)
Whiteboard: [games]
Component: Video/Audio → Web Audio

Comment 10

6 years ago
What do you mean by overbuffering?  Is there a test case?
Reporter

Comment 11

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

Updated

6 years ago
Keywords: testcase-wanted
Reporter

Comment 12

6 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.
Reporter

Comment 13

6 years ago
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?
Flags: needinfo?(mbest)

Comment 15

6 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.
Do you still see this? We fixed a related problem a week or so ago.
Flags: needinfo?(grantgalitz)
Reporter

Comment 17

6 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...).
Flags: needinfo?(grantgalitz)
Reporter

Comment 18

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

Comment 19

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

Comment 20

6 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
Reporter

Updated

6 years ago
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
Grant did you file a bug for your previous comment?
Reporter

Comment 22

6 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.
You need to log in before you can comment on or make changes to this bug.