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. So you end up making the system do more work in the hopes
that there will be some overlap. Basically, later stages get blocked
waiting for their input buffer to fill, which means that you're not
really getting very much overlap at all, but plenty of multi-
threading overhead. At least that's the predicted result - I admit
that nobody has tried this, to my knowledge.
Brian Willoughby
Sound Consulting
On Sep 7, 2007, at 18:25, Ralph Giles 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?
-r
_______________________________________________
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
