From: Marcin Bukat <marcin.bukat_at_gmail.com>
Date: Wed, 22 Jan 2014 09:49:13 +0100

Perhaps I am missing something but why buflib-on-buflib is used actually?


2014/1/21 Thomas Martitz <kugel_at_rockbox.org>

> Hello folks,
>
> I wanted to request comments on my talk rewrite on gerrit[1].
>
> For this who haven't heard about it yet I'll summarize what it is about:
>
> I found that the cache management for TALK_PARTIAL_LOAD is immensely
> inefficient. It allocates 64 slots for talk clips, each as big as the
> biggest clip in the voice file (such that any clip will fit into any of
> these slots). But the biggest clip can be easily more than 3x as big as the
> average which results in a major waste of RAM.
>
> My rework changes the cache management to use buflib for it. With buflib a
> max. buffer size (currently 100k) is specified and buflib will load as many
> clips as possibly fit (most memory efficient), one buflib allocation per
> clip. Buflib natually keeps this cache compact as newer clips replace the
> least-recently-used ones. Other implications of buflib apply, such that the
> clips can move during compaction, which is a problem for DMA access on
> hwcodec. Therefore clips will be copied to a small static buffer (1k)
> before decoding, to keep things simple.
>
> Note that this is not to be confused with that the clip cache itself is a
> buflib allocation which is already in git master. This rewite uses a nested
> buflib instance to load clips into the large clip cache buffer.
>
> Later commits apply this new clip management to be also used for
> !TALK_PARTIAL_LOAD and even for the thumbnails (for dirtalk), so that there
> is only a single algorithm for all kinds of clips and targets
> (!TALK_PARTIAL_LOAD still loads the entire voice file into RAM but uses the
> same code to access each clip).
>
> Some numbers to see the effect: On the clipv1 caching 64 clips of
> english.voice required almost 300k. The code now uses a 100k buffer which
> fits ~60 clips on average. For german.voice it previously used ~390k for
> 64 slots whereas the new code fits 54 clips into 100k. Note that 390k is a
> significant share of the total RAM available on the clipv1.
>
> In essence the rewrite is a huge win for lowmem and also achieves a more
> unified code in talk.c across targets and clip types.
>
> What do you think? Please commit.
>
> I would like to push this fairly soon, unless some speaks up. I tested on
> e200, clipv1 and Player.
>
> [1]: http://gerrit.rockbox.org/r/#/q/status:open+project:rockbox+
> branch:master+topic:talk-rewrite,n,z
>
> Best regards.
>
Received on 2014-01-22