[Flac-dev] Re: multiple core support

2007-09-07 Thread Harry Sack
2007/9/7, Brian Willoughby [EMAIL PROTECTED]: I really should have just said that it will require some testing to make sure the FLAC API can handle writing the same file from multiple threads. It may not turn out to be complicated at all. The FLAC decoder has its own code for writing PCM

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

[Flac-dev] FLAC__FrameHeader's blocksize element

2007-09-07 Thread Erik de Castro Lopo
Hi all, I've found that the FLAC__FrameHeader struct's blocksize member has values limited to the range (0, FLAC__MAX_BLOCK_SIZE] where FLAC__MAX_BLOCK_SIZE is 65535. In the encoder, what determines the size of a block? Cheers, Erik --

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

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

2007-09-07 Thread Brian Willoughby
Ralph, The problem is that there is no clear advantage, at least in terms of multiple cores, to the approach you're asking about. In order to allow each stage of the codec to overlap, you need smart buffering between each stage. That adds code and complexity which isn't there