dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: talk rewrite

talk rewrite

From: Thomas Martitz <>
Date: Tue, 21 Jan 2014 23:58:37 +0100

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.


Best regards.
Received on 2014-01-21

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy