From: Jens Arnold <jens_at_jens-arnold.net>
Date: Tue, 30 Oct 2012 07:55:39 +0100

> What can it bring good for rockbox:

(shortened list)
> - It removes the need for overlays. If plugin load fails in pluginbuf
> due to lack of ram, audiobuf is grabbed and plugin is loaded there.
> This is transparent and properly coded plugin doesn't need to know
> where it is loaded.

> - It is the first step to move some functionality from the core to the
> loaded on demand plugins (core plugins?)

> - Maybe even dynamicaly sized pluginbuf and codecbuf

> - It is questionable if this is desired thing for SH. This targets are
> very limited both in binsize allowed and in ram. If someone move some
> parts of the core to the loaded on demand core plugins (like database
> for example) it may still be beneficial. New toolchain with -flto and

I think that due to the arguments quoted above, the elf loader does make
sense on lowmem targets (i.e. SH1) as well. Due to the small plugin RAM,
there are several overlay plugins atm.

The first step towards dynamic pluginbuf would be to make the pluginbuf
size configurable, so that the user could decide whether he wants to be
able to use plugins while music is playing, or whether he prefers the
improved battery runtime of a larger audiobuf. One could even set the
pluginbuf size to zero, maximising the audiobuf (and causing *every*
plugin to stop playback).

On demand core plugins is in fact something I've been thinking about
*especially* for hwcodec. Integrating the PCM codec will probably
increase binsize quite a bit, and (1) there are various hard size limits
(part of which could be worked around by having a proper bootloader
though), plus (2) someone who doesn't use PCM would probably again
prefer a larger audio buffer.

The biggest problem is probably MIPS (and not SH1), due to the fact that
no MIPS developer has been around for quite some time now.

-- 
Mit freundlichen Grüßen / Best Regards
Jens Arnold

Received on 2012-10-30