Re: [Flac-dev] Re: multiple core support

2007-09-07 Thread Josh Coalson 
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 would take a specialty file-based encoder using an independent
frame encoder to do and even that is not trivial.

--- Harry Sack [EMAIL PROTECTED] wrote:

 2007/9/7, Avuton Olrich [EMAIL PROTECTED]:
 
  On 9/6/07, Harry Sack [EMAIL PROTECTED] wrote:
   it's really not complicated I think: only api changes to write on
 any
 
  Please get started writing a patch, immediately.
 
 
 
 I'm just an IT student and I have no time for that :)
 I also didn't study the flac API in detail but I know it's perfectly
 possible because I made a avi encoder running on multiple threads
 once and
 it's exactly the same for audio data.
 
 --
  avuton
  --
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
 
  ___
 Flac-dev mailing list
 Flac-dev@xiph.org
 http://lists.xiph.org/mailman/listinfo/flac-dev
 



   

Building a website is a piece of cake. Yahoo! Small Business gives you all the 
tools to get online.
http://smallbusiness.yahoo.com/webhosting 
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [Flac-dev] Re: multiple core support

2007-09-07 Thread Ralph Giles 
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?

 -r
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev