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
code.

> 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
scene.

Thanks!

-- 
Rafaël Carré