1221830 - double maximum realtime convolver stage size

Status: RESOLVED FIXED

(Core :: Web Audio, defect, P1)

Description

[Karl Tomlinson (:karlt)]

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.

Comment 1

[Karl Tomlinson (:karlt)]

Attachment: realtime convolution test

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

Comment 2

[Karl Tomlinson (:karlt)]

Attachment: MozReview Request: bug 1221830 use WEBAUDIO_BLOCK_SIZE constant in Reverb methods r?padenot

bug 1221830 use WEBAUDIO_BLOCK_SIZE constant in Reverb methods r?padenot

Comment 3

[Karl Tomlinson (:karlt)]

Attachment: MozReview Request: bug 1221830 use WEBAUDIO_BLOCK_SIZE slice size for background convolver thread 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.

Comment 4

[Karl Tomlinson (:karlt)]

Attachment: MozReview Request: bug 1221830 use WEBAUDIO_BLOCK_SIZE constant in FFTConvolver r?padenot

bug 1221830 use WEBAUDIO_BLOCK_SIZE constant in FFTConvolver r?padenot

Comment 5

[Karl Tomlinson (:karlt)]

Attachment: MozReview Request: bug 1221830 double maximum realtime convolver stage size to 2048 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 6

[Paul Adenot (:padenot)]

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 7

[Paul Adenot (:padenot)]

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 8

[Paul Adenot (:padenot)]

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 9

[Paul Adenot (:padenot)]

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.

Comment 10

[Karl Tomlinson (:karlt)]

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.

Comment 11

[Pulsebot]

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

Comment 12

[Carsten Book [:Tomcat]]

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