ReverbConvolver limits the size of stages on the rendering thread and staggers their FFT calculations to avoid doing too much work during the processing of a single block. RealtimeFrameLimit consists of 11 MaxRealtimeFFTSize stages and the initial smaller size-doubling stages. There are 8 phase-offset positions (1024/128) for the MaxRealtimeStages, and so, at 3 offsets, two MaxRealtimeFFTSize stages are performing their FFTs at the same time. Further, all the initial smaller size-doubling stages perform their FFTs while processing a block that processes two MaxRealtimeFFTSize stages. The computation during that block is then similar to performing FFTs for three MaxRealtimeFFTSize stages. If doing this much computation during one block anyway, we should instead double MaxRealtimeFFTSize to double the efficiency of the stage. And we can stagger the stages so that the maximum FFT work during any processing block is reduced.

I'll submit patches that reduce rendering thread CPU usage for this testcase by 18%.

bug 1221830 use WEBAUDIO_BLOCK_SIZE constant in Reverb methods r?padenot

bug 1221830 use WEBAUDIO_BLOCK_SIZE slice size for background convolver thread r?padenot as with the main thread. The comment was incomplete as ReverbConvolverStage also supports multiples of the FFT halfsize, but only values up to WEBAUDIO_BLOCK_SIZE.

bug 1221830 use WEBAUDIO_BLOCK_SIZE constant in FFTConvolver r?padenot

bug 1221830 double maximum realtime convolver stage size to 2048 r?padenot Now, the most FFT work that happens during one realtime processing block is when one 2048-size stage and the 256-size stage are performed at the same phase-offset. Before FFT timing was controlled by initial input buffer offset (bug 1221831), two 1024-size stages as well as the 512- and 256-size stages performed FFTs at one offset. Thus, the maximum work in one block is reduced by a ratio of about 11 to 9. Measurements also indicate a similar reduction in total rendering thread CPU usage. Previously the alignment of the eleven 1024-size realtime stages was such that, in three consecutive blocks, two 1024-size stages would peform their FFTs. Now, the 2048-size stages is aligned so that none of these perform their FFTs in consecutive blocks.

Comment on attachment 8683440 [details] MozReview Request: bug 1221830 use WEBAUDIO_BLOCK_SIZE constant in Reverb methods r?padenot https://reviewboard.mozilla.org/r/24341/#review21843

Comment on attachment 8683441 [details] MozReview Request: bug 1221830 use WEBAUDIO_BLOCK_SIZE slice size for background convolver thread r?padenot https://reviewboard.mozilla.org/r/24343/#review21845

Comment on attachment 8683442 [details] MozReview Request: bug 1221830 use WEBAUDIO_BLOCK_SIZE constant in FFTConvolver r?padenot https://reviewboard.mozilla.org/r/24345/#review21847

Comment on attachment 8683443 [details] MozReview Request: bug 1221830 double maximum realtime convolver stage size to 2048 r?padenot https://reviewboard.mozilla.org/r/24347/#review21857 ::: dom/media/webaudio/blink/ReverbConvolver.cpp:138 (Diff revision 1) > + phaseLookup[m_stages.Length() % ArrayLength(phaseLookup)]; Hrm, not having much documentation for all the rest of the blink code did not help understanding this, but I think I get it now. The numbers are a bit magical at first glance though.

https://reviewboard.mozilla.org/r/24347/#review21857 > Hrm, not having much documentation for all the rest of the blink code did not help understanding this, but I think I get it now. The numbers are a bit magical at first glance though. They are a bit magical I'm afraid. I think there is sense in positioning FFTs mid way between FFTs of the previous stage during the doubling process. For positioning the five MaxRealtimeFFTSize stages across the 16 positions, I didn't come up with the any nice algorithm. It turned out that there were not many options where these stages were not aligned in consecutive blocks and not aligned with the FFTs of the next two smaller sizes. I picked the only option where the first MaxRealtimeFFTSize position was consistent with the doubling process and we didn't perform FFTs for two MaxRealtimeFFTSize stages and one MaxRealtimeFFTSize/2 stage in three consecutive blocks.

https://hg.mozilla.org/integration/mozilla-inbound/rev/1fb6658a9639 https://hg.mozilla.org/integration/mozilla-inbound/rev/cc171f73d773 https://hg.mozilla.org/integration/mozilla-inbound/rev/994ed6081118 https://hg.mozilla.org/integration/mozilla-inbound/rev/c7695f2acc27

https://hg.mozilla.org/mozilla-central/rev/1fb6658a9639 https://hg.mozilla.org/mozilla-central/rev/cc171f73d773 https://hg.mozilla.org/mozilla-central/rev/994ed6081118 https://hg.mozilla.org/mozilla-central/rev/c7695f2acc27