On Wed, Jul 22, 2009 at 2:54 AM, Chen-Po Sun<chenpo at fmod.org>
wrote:> Hi guys,
>
> I'm currently working on a CELT implementation for FMOD, and one of the
> things we want to do is have all memory required allocated beforehand.
> This is before we have any information about what sounds will be played.
>
> We would like to create all of our CELTDecode instances up front.
> Because celt_mode_create() requires a sample rate and number of channels
> passed in, this doesn't seem like it is currently possible.
>
> What I am thinking of doing is calling celt_mode_create() and
> celt_decoder_create() up front with the maximum values for sample rate
> and number of channels, this will allocate all the memory we need. Then
> when we actually go to play a sound and know the rate and number of
> channels, we can fix up the appropriate mode parameters before decoding.
>
> The only problem I can see is that eBands and window are generated when
> celt_mode_create() is called. I'm thinking I can just generate these in
> our encoder, and store it in our sound banks. Then when we go to fix up
> the mode members before decoding, set the appropriate eBand and window.
>
> Does this sound okay to you guys? Is there anything I might have
> overlooked that will make this approach not-doable?
The pre-computed mode parameters part of what you're suggesting is
already done: --enable-static-modes It's not well documented since
until now it's only been used for support for DSPs without any
floating point (the mode creation logic is the only part of CELT which
is currently floating point only).
The data stored in the mode structure is all read-only so the mode can
be shared among many encoders and decoders. As a result you'll
probably want to create (or load) the modes for all the configurations
you intend on using and keep them around.
Another alternative decoder_create I'd simply create a simple malloc
replacement that pre-allocated slots for N maximum sized decoders and
allocated from that. This would have the advantage of not requiring
any changes when you update to later versions of CELT. Environments
without real memory management were a consideration while the code was
written, ... so long as your malloc never fails you don't even need a
free().
We could manage to take the allocations out of encoder/decoder_create
for the static mode case by simply making the allocated parts into
statically sized arrays sized for the worst case of the supported
modes. And adding a set of encoder_zeroize/decoder_zeroize functions
which you give a mode pointer and a pointer to an appropriately sized
blob of memory. This would make possible to completely avoid
allocation, even for codec setup. I'll let JM give his opinion on
this.