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
currently.
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 wa
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
--
---
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 signif
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
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 stu
