This builds the band limited tables for each range index individually as
required.
--HG--
extra : rebase_source : 022665e3b83b82bcdcec3cabf3ddda9c2dce2ebf
If we build the band limited tables after the fundamental frequency is known,
we can exclude partials that are above the nyquist frequency for the sampling
frequency being used.
We rebuild the band limited tables each time we see a request for data for a
lower fundamental frequency so we have the required partials.
--HG--
extra : rebase_source : 067075c7c8a90580650bf850c50ca7d8fc1eb6ff
We need to store the components used to create the PeriodicWave for later use
if we want to be able to build the band limited tables lazily.
--HG--
extra : rebase_source : d760433e6fe5490a60da761be7e2148a6504d20d
The patch changes all uses of SizeOfIncludingThisMustBeUnshared() to
SizeOfIncludingThisIfUnshared(). This incurs the (tiny) cost of an unnecessary
IsReadonly() check for guaranteed-unshared strings, but avoids the possible
assertion failures that would occur when MustBeUnshared() was used incorrectly
on shared strings, which is an easy mistake to make.
--HG--
extra : rebase_source : b1e91f1c19bcbe0521b0ce461d6c90512ca938ef
The zeroth component is not removed from the BufferComplexMultiply() call so
as not to disrupt alignment.
The mOutputBuffer[halfSize].i assertions are removed because the code no
longer uses these components, and so their values are irrelevant.
--HG--
extra : rebase_source : 96014bdb66a86e1d764979f7b1a313c24196a60b
extra : histedit_source : 59ef41301d48a7f80798d8dbecc43aa85703c26f
This increases the maximum PeriodicWave size to 8192 and adds an optimization
to use 8192 elements only in the case where we receive more than 4096
components. In accordance with the spec, a maximum number of components is no
longer enforced.
--HG--
extra : rebase_source : ecb9a401fabdb14f23f690c44944ece434599055
Efficiency is proportional to stage size, so start with the largest size
possible.
--HG--
extra : rebase_source : 34915efce1eb94e18f53adf35dc939301242467a
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.
--HG--
extra : rebase_source : 7265374c1642661db1d4f4d630ddc8294be689c7
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.
--HG--
extra : rebase_source : 34f11834dd425075e8948f47dcc5283dcb50fc42
