From: Thomas Martitz <kugel_at_rockbox.org>
Date: Wed, 22 Jan 2014 13:22:01 +0100

Am 22.01.2014 09:49, schrieb Marcin Bukat:
> Perhaps I am missing something but why buflib-on-buflib is used actually?
>
>
> 2014/1/21 Thomas Martitz <kugel_at_rockbox.org <mailto: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.
>
>

First: please do not top post.

Buflib-on-buflib is used for mainly for 2 reasons:
a) To simplify putting an upper bound to the memory used for the clip
cache. Buflib takes care of that automatically.
b) You don't want core_alloc() for each clip because new allocations
always shake playback a bit. Remember that shrinking the audio buffer is
not (yet) possible without stopping playback (patches are very welcome,
though!) so you better try to avoid sporadic micro-allocations when
possible.

Hope that answers your question.

Best regards.
Received on 2014-01-22