|
Rockbox mail archiveSubject: Re: talk rewriteRe: talk rewrite
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 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |