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)

46 Branch
defect

Tracking

()

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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: perf
Priority: -- → P2
Rank: 25
Component: Audio/Video → Web Audio
Depends on: 897796
Mass change P2->P3 to align with new Mozilla triage process.
Priority: P2 → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.