In my testcase, we had at most 3 members in mChanges, but it's small enough that 5 should be a good guesstimate-based staring value. This eliminates about half of the nsTArray badness I was seeing.

Comment on attachment 725985 [details] [diff] [review] Patch (v1) Review of attachment 725985 [details] [diff] [review]: ----------------------------------------------------------------- ::: content/media/TimeVarying.h @@ +213,5 @@ > // The time at which the value changes to mValue > Time mTime; > T mValue; > }; > + nsAutoTArray<Entry, 5> mChanges; I'd prefer this parameter to be exposed as a parameter to the TimeVarying template so we can vary it by user.

Comment on attachment 725985 [details] [diff] [review] Patch (v1) Review of attachment 725985 [details] [diff] [review]: ----------------------------------------------------------------- I guess I meant -

Please figure out which TimeVarying values actually need auto elements, and how many, and then attach patches to set those values here. Thanks.

It seems like most of the badness comes from the mBlocked member, we don't need to reserve storage for other TimeVarying's.

Comment on attachment 726169 [details] [diff] [review] Patch (v2) Review of attachment 726169 [details] [diff] [review]: ----------------------------------------------------------------- OK. The fact that we have entries in the mBlocking array indicates that we must be stuttering, which is really bad, so we need to fix it. Once we've fixed it we can probably put this back to zero.

Yes, we are indeed stuttering...

Mass moving Web Audio bugs to the Web Audio component. Filter on duckityduck.