636894 - Audio 'MozAudioAvailable' event timing behaving poorly

Status: VERIFIED FIXED

(Core :: Audio/Video, defect)

Description

[Charles J. Cliffe]

User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b12pre) Gecko/20110220 Firefox/4.0b12pre
Build Identifier: 4.0b12pre (2011-02-21)

The Audio events in build 4.0b12pre (2011-02-20) run smoothly at the given URL,  however if you use a build after that, such as 4.0b12pre (2011-02-21) or later the event timing is running strangely.  

It's causing anything that relies on having the audio sync'd (almost every audio demo written so far) to behave as if the data is arriving in quick bursts, effectively making the framerate look very low for anything depending on that information.

Some additional broken URLs are:

BeatDetektor demos, i.e.: 
http://cubicvr.org/CubicVR.js/bd3/BeatDetektor3HD.html 

Most of the demos on:
http://vocamus.net/dave/?p=1188

The city visualizer section of:
http://videos.mozilla.org/serv/mozhacks/flight-of-the-navigator/

and many, many more including the Audio API team's currently unreleased no-comply demo.

Reproducible: Always

Steps to Reproduce:
1. Go to http://www.audioscene.org/scene-files/ccliffe/AudioTiming/debug.html with a build from on or before February 20th.
2. Observe the counters incrementing smoothly.
3. Grab a build from after February 20th
4. Observe the counters incrementing in jerky non-linear steps

Actual Results:  
Builds before the 21st are fine, anything after the timer is behaving strangely

Expected Results:  
Both should behave the same

Comment 1

[Matthew Gregan [:kinetik]]

Fairly sure this is a result of the AUDIO_DURATION_MS change in bug 634787.  Waiting for a build to confirm.

Comment 2

[Charles J. Cliffe]

Additional test that calculates the event timing offset and average independently using Date(), not perfect but might help:

http://www.audioscene.org/scene-files/ccliffe/AudioTiming/debug2.html

Comment 3

[Matthew Gregan [:kinetik]]

I modified the testcase to save the last 30 delta times between MozAudioAvailable firing.  I think this reveals that AUDIO_DURATION_MS is the cause of the regression.

Current trunk:
recentDelays: [10, 8, 9, 8, 8, 93, 14, 10, 8, 9, 8, 101, 15, 9, 9, 8, 9, 8, 92, 15, 9, 9, 8, 8, 101, 19, 9, 9, 8, 9]

With AUDIO_DURATION_MS back to 40ms:
recentDelays: [16, 26, 12, 22, 24, 16, 22, 14, 38, 16, 18, 28, 9, 33, 14, 26, 12, 30, 38, 13, 25, 13, 27, 40, 9, 31, 9, 31, 9, 31]

With patch backed out:
recentDelays: [40, 15, 32, 10, 23, 11, 29, 40, 14, 26, 11, 28, 13, 29, 39, 10, 29, 8, 34, 38, 9, 31, 9, 31, 8, 32, 40, 11, 29, 9]

Comment 4

[Matthew Gregan [:kinetik]]

Attachment: patch v0

Short term fix: revert the AUDIO_DURATION_MS part of bug 634787.

It's worth revisiting that change later (post FF4) to see if we can still reduce the overhead for normal playback (~27% to ~14% CPU in a debug build, probably less in optimized), but we'll need to look at decoupling the audio event dispatch stuff so that it doesn't regress like this bug demonstrates.

Comment 5

[Matthew Gregan [:kinetik]]

Bug 636941 for the post-FF4 attempt at this.

Comment 6

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 515286 [details] [diff] [review]
patch v0

r+ before a?, please!

Comment 7

[Matthew Gregan [:kinetik]]

http://hg.mozilla.org/mozilla-central/rev/635bb4ffe6ad

Comment 8

[u279076]

Verified FIXED in Firefox 4.0rc1.