Open
Bug 1271425
Opened 9 years ago
Updated 2 years ago
Playing many looping sources in Web Audio API starves CPU
Categories
(Core :: Web Audio, defect, P3)
Tracking
()
NEW
People
(Reporter: m, Unassigned)
References
(Depends on 1 open bug)
Details
(Keywords: perf)
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20160425114621
Steps to reproduce:
Load http://mbitsnbites.github.io/misc/web-audio-many-notes.html ... which essentially start():s a few hundred looping AudioBufferSource nodes, each followed by a Gain node that does a short zero->one->zero envelope cycle.
Actual results:
Each AudioBufferSource node consumes CPU indefinitely, starting from the point in time when it is start():ed, even when the Gain node amplitude is zero.
On a fairly weak dual core 1.7 GHz AMD CPU the Firefox process maxes out at 100% CPU before 256 notes have been played, and the sound starts to break up (glitching).
Expected results:
When the Gain node reaches zero, and there are no more automation events, AND the JavaScript reference to the Gain node has been dropped, the AudioContext should drop the source + gain chain since it will never generate nor process any sound again, ever.
This is, in my mind, a fairly trivial and common setup, and as such deserves some optimization love.
Additional info: Gecko also seems to have performance problems when there are many pending source nodes (to be started in the future). On my phone, the sound glitches from the very first note, indicating that the inactive nodes eat unnecessarily much CPU.
Updated•9 years ago
|
Updated•9 years ago
|
Priority: -- → P2
Updated•8 years ago
|
Rank: 25
Updated•8 years ago
|
Component: Audio/Video → Web Audio
Comment 2•7 years ago
|
||
Mass change P2->P3 to align with new Mozilla triage process.
Priority: P2 → P3
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•