On Sat, 18 Jul 2009 16:12:33 -0400 Bryan Jacobs <[email protected]> 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é
signature.asc
Description: PGP signature
