--- Ralph Giles <[EMAIL PROTECTED]> wrote:
> On Fri, Sep 07, 2007 at 04:59:50PM -0700, Josh Coalson wrote:
> > it actually is complicated.  the libFLAC api is not suited to a
> > multithreaded design because the i/o is stream-based, not file-
> > based.  flac(.exe) is the file-based wrapper around libFLAC that
> > allows it to work on files.  the way libFLAC buffers data is also
> > impossible to parallelize without significantly changing the api.
> It seems like buffering (especially compressed) blocks and writing
> them 
> to the stream in sequence wouldn't be a problem. Is there something
> in 
> the way the blocking decisions are made that makes it hard to divide
> the 
> input audio this way?

if the constraint of sequential output is kept, I was thinking that
to get maximum efficiency, the library would need to be able to get
samples out of order to keep all the threads going at max speed, or
might have to grow buffers arbitrarily large if fed samples
sequentially because of the different processing requirements of
different blocks.  extreme example: a block that goes through high-
order LPC processing followed by several silence or noise blocks.


Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, 
photos & more. 
Flac-dev mailing list

Reply via email to