|
Rockbox mail archiveSubject: talk rewritetalk rewrite
From: Thomas Martitz <kugel_at_rockbox.org>
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. [1]: http://gerrit.rockbox.org/r/#/q/status:open+project:rockbox+branch:master+topic:talk-rewrite,n,z Best regards. Received on 2014-01-21 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |