AudioEventTimeline is the code that handles AudioParam for Web Audio API. It has a number of issues: - It's way too complicated - It has bugs (we don't support events of different types at the same time, SetTargetAtTime is buggy in a couple different ways) - It's not fast enough, even with baku's optimizations I think we should just rewrite it to be simpler, correct and faster. Additionally, it's a opportunity to implement the couple spec changes that happened in the area. I'm taking this bug to work on it on the side (I've got a design ready), but feel free to take it as I won't get to it immediately.

Remaining from bug 1140448 comment 0: "- We should determine, in the 128 ticks block, the boundaries for which to compute which event, and then compute the actual values in one pass after - Then if really needed, we can speed it up with SIMD, since it's all linearly independent functions Bonus points if we can make sure this code is independent enough of Gecko so that we can test it easily (as it is now), and nicely emscriptenable so that web app can do content-side (as opposed to audio thread-side) computations, as they often want to do: https://github.com/jsantell/web-audio-automation-timeline"

Mass change P1->P2 to align with new Mozilla triage process

Moving to p3 because no activity for at least 1 year(s). See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information