Open
Bug 666219
Opened 13 years ago
Updated 2 years ago
Very high CPU usage during playback on jsmad.org
Categories
(Firefox :: General, 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
Comment 1•13 years ago
|
||
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.
Reporter | ||
Comment 2•13 years ago
|
||
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
Comment 3•13 years ago
|
||
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.
Comment 4•13 years ago
|
||
@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)
Comment 5•13 years ago
|
||
Max: The data number for Aurora 6.0a2 shouldn't be right anymore, the fix for that has landed already.
Comment 6•13 years ago
|
||
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
Reporter | ||
Comment 7•13 years ago
|
||
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%
Comment 8•13 years ago
|
||
(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?
Comment 9•13 years ago
|
||
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.
Comment 10•13 years ago
|
||
Can someone describe how the work-around works in Firefox 5?
Comment 11•13 years ago
|
||
(In reply to comment #10)
> Can someone describe how the work-around works in Firefox 5?
Chris, smaug was the one that suggested this.
Comment 12•13 years ago
|
||
(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.)
Comment 13•9 years ago
|
||
jsmad.org testcase is gone, site has been taken over
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•