Rockbox mail archiveSubject: Re: Buffering Explanation
Re: Buffering Explanation
From: Rafaël Carré <rafael.carre_at_gmail.com>
Date: Sun, 19 Jul 2009 01:30:09 +0200
On Sat, 18 Jul 2009 16:12:33 -0400
Bryan Jacobs <no_at_landwarsin.asia> wrote:
> Attached is a document describing my proposed changes to the
> buffering system.
Thanks for this document!
I think it is very helpful to represent the current state of buffering
> In the event that these are too controversial, we
> can tone it down and eliminate the issue of fragmentation while still
> serving Wavpack's needs by only allowing "chunky" allocations to
> extend at buf_widx - this will mimic the behavior of one file having
> the size of both the normal and correction files.
I have a question : would the chunky allocations happen
BUFFERING_DEFAULT_FILECHUNK bytes at a time ? (currently 32kB, but I
think this should be lowered for some -short on memory- targets)
The down side you mentioned (codecs relying on reading small amounts of
data repeatedly from the buffer) doesn't make sense to me, I would
think a chunk would be de-allocated as soon as another chunk has been
read for the same file.
Here I suppose codecs never seek backwards in the bitstream, but I may
be wrong since my knowledge in codecs bitstreams is very close to 0.
Please just bash me if I'm wrong ;)
> We can also do the codec-specific buffering code. At any rate, the
> summer is only half over and we're making steady progress, so things
> are in good shape.
That is an option, we should really measure the performance loss and
relate it to the complexity added to buffering for handling two
different buffering schemes.
I have understood that few people understand the current buffering
code, so it is very nice to see you working on it, and makes me want to
continue reading it until I can understand what happens behind the
-- Rafaël Carré