Open Bug 666219 Opened 13 years ago Updated 2 years ago

Very high CPU usage during playback on jsmad.org

Categories

(Firefox :: General, defect)

x86_64
macOS
defect

Tracking

()

UNCONFIRMED

People

(Reporter: maxoueb, Unassigned)

References

()

Details

(Keywords: perf)

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_7) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.24 Safari/535.1 Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20100101 Firefox/5.0 I'm experiencing a pretty heavy CPU usage in Firefox 5 (as in, continuously at 100+% CPU), when playing a local MP3 file on jsmad.org Capture: http://cl.ly/2b2p0l3z0E402z2I3f2h Config: Mac OS X 10.6.7 2.53 GHz Intel Core 2 Duo 4 GB 1067 MHz DDR3 NVIDIA GeForce 9400M, 256 MB Intel® X25-M SSD Browser: Firefox 5 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20100101 Firefox/5.0 Reproducible: Always Steps to Reproduce: 1. Go to http://jsmad.org 2. Open an MP3 file 3. Play Actual Results: heavy CPU usage in Firefox during playback (as in, continuously at 100+% CPU) Expected Results: 20-25% CPU usage during playback JSmad Github thread: https://github.com/nddrylliog/jsmad/issues/18
Additional details: on Firefox 4.0/WinXP and Firefox 6.0a2/WinXP it's stable at 8-9% CPU usage. On Firefox 4.0.1/Fedora15 it's stable at 20-25% CPU usage.
On the exact same machine (loading the same MP3 file): - Chrome Canary (14.0.798.0 canary): average of 19.4% CPU usage - Firefox Aurora 6.0a2 (Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0a2) Gecko/20110619 Firefox/6.0a2): average of 104% CPU usage Something is definitely not right with Firefox/Mac
This is related to issue 665000 https://bugzilla.mozilla.org/show_bug.cgi?id=665000 . It is caused by the postMessage hack used to replace setTimeout to make it work in background tabs as well. This is a Firefox 5 -specific issue, because the code is using a worker-based approach when MozBlobBuilder is available.
@Max are those Firefox 6 results recent? (less than 10 minutes) I have recently updated jsmad.org to use the latest version of Jussi's audiolib.js, which includes a much better solution for Firefox 6. If not, please retest with that so we can see if Jussi's hypothesis is right (ie. if it's because of the postMessage hack)
Max: The data number for Aurora 6.0a2 shouldn't be right anymore, the fix for that has landed already.
I personally think the clamping should be disabled by default until 6.0, where a workaround exists, but I bet you guys on the other end don't like that idea too much. :P
I just updated Aurora (Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0a2) Gecko/20110621 Firefox/6.0a2), and the results are indeed better, CPU load is now between 43% and 78%
(In reply to comment #7) > I just updated Aurora (Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; > rv:6.0a2) Gecko/20110621 Firefox/6.0a2), and the results are indeed better, > CPU load is now between 43% and 78% That's still much, much worse than on Win32 and Linux. Something's definitely fishy. (In reply to comment #6) > I personally think the clamping should be disabled by default until 6.0 That's my opinion as well. I was disappointed that such a bug was in Firefox 5.0 and that the attitude was "we'll see what we can learn from this release and apply it to 6.0". Are stable releases considered alpha quality now?
No, stable releases aren't considered alpha quality. But throttling background tabs was important for overall CPU usage. We knew of one thing, this turned out to be another. Note that Chrome is also going to be (or is) doing the same throttling. Their Audio APIs are different enough where they don't run into the mismatch that causes problems with this type of library. We need to work on a solution so that libraries that want to produce sound in the background like jsmad can continue to work without having to be timer-based.
Can someone describe how the work-around works in Firefox 5?
(In reply to comment #10) > Can someone describe how the work-around works in Firefox 5? Chris, smaug was the one that suggested this.
(In reply to comment #10) > Can someone describe how the work-around works in Firefox 5? Well, I didn't write it (Jussi did), but I think here's the gist of it: https://github.com/jussi-kalliokoski/audiolib.js/blob/master/lib/audiolib.js#L1020 (lines 1020 to 1032) (In reply to comment #9) > No, stable releases aren't considered alpha quality. But throttling > background tabs was important for overall CPU usage. We knew of one thing, > this turned out to be another. That's understandable, considering that right now, very few applications do background audio in pure JS. However, if FF5 reveals to be a very bad platform to do that, there are many chances that there won't be more applications doing that. Hence the proposal to postpone timeout clamping until FF6, where we have a better solution available. > Note that Chrome is also going to be (or is) doing the same throttling. > Their Audio APIs are different enough where they don't run into the mismatch > that causes problems with this type of library. I also have interrogations about why there are two APIs, and whether developers will have to juggle between them indefinitely but that discussion is definitely too broad for this bug report :) > We need to work on a solution so that libraries that want to produce sound > in the background like jsmad can continue to work without having to be > timer-based. As far as I know, that solution exists, and has been implemented in Firefox 6 (Audio workers). Jussi has integrated this solution in audiolib.js 0.4.6, and it works like a charm in Aurora. However, with FF5, we're stuck with the ugly postMessage hack. Hence, again, the proposal to only clamp timeouts starting with FF6. (I realize that it's too late for FF5.0, but I've heard Firefox is going to get the continuous silent update system, so I'm still hoping.)
jsmad.org testcase is gone, site has been taken over
Keywords: perf
See Also: → 665000
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.