Re: Re: multiple core support

--- Ralph Giles <gilesxiph.org> 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.

Josh


       
____________________________________________________________
________________________
Take the Internet to Go: Yahoo!Go puts the Internet in your
pocket: mail, news, photos & more. 
http://mobile
.yahoo.com/go?refer=1GNXIC
_______________________________________________
Flac-dev mailing list
Flac-devxiph.org
http:
//lists.xiph.org/mailman/listinfo/flac-dev