[CELT-dev] Allocating all memory up front

[Chen-Po Sun]

Hi,

Thanks for the feedback guys. The STATIC_MODES thing was exactly what I 
was after. I wasn't aware that the CELTmode was read-only, I was 
thinking we would need one per sound instance, but it looks like we 
don't, so there's another memory saving! We could probably even store 
the whole mode as part of our sample banks or something.

To answer Jean-Marc's question, we will be allocating into a chunk for 
now, but it would be nice if all allocations were taken out of the 
decoder_create (for static mode) as Gregory mentioned, and put into 
statically sized arrays.
This will make things a lot easier when it comes time to get this stuff 
working on the PS3 SPUs. We do a lot of DMA's back and forth, and it 
would also mean we don't have to fix up pointers everytime we go from 
PPU to SPU and vice versa.
It is probably something we would eventually end up doing unless it is 
already part of the official lib before then ;)

Chen-Po Sun
Firelight Technologies
http://www.fmod.org/



Gregory Maxwell wrote:
> 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.
>
>
>