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?

Flac-dev mailing list

Reply via email to