Rockbox mail archiveSubject: Re: [TTS-In-Core] Status report
Re: [TTS-In-Core] Status report
From: Alex Bennee <kernel-hacker_at_bennee.com>
Date: Wed, 9 Jun 2010 10:51:17 +0100
On 8 June 2010 14:42, Rafaël Carré <rafael.carre_at_gmail.com> wrote:
> On Tue, 8 Jun 2010 13:57:18 +0100
> Delyan Kratunov <delyan.kratunov_at_gmail.com> wrote:
>> So the question here
>> is whether malloc in core (even as a loadable component) is an
>> absolute no-do. I'm not going to try and hide the ugly truth - the
>> memory fragmentation is MASSIVE, even with something like tlsf.
> Every no-do can be discussed.
> If flite would be the only code which needs malloc in core, malloc
> could be statically linked to it.
How long does a codec hang around and is it's memory freed when no
Perhaps one option is to create a memory pool style malloc
implementation so individual plugins could request a chunk of memory
as a pool (from the sample buffer?) which can then be used malloc
style within the plugin. When the plugin is done the whole pool can be
returned as one block to the sample buffer.
Perhaps this would provide a middle way solution to a global malloc
implementation and all the issues that raises?
-- Alex, homepage: http://www.bennee.com/~alex/ http://www.half-llama.co.ukReceived on 2010-06-09