2007/9/9, Josh Coalson [EMAIL PROTECTED]:
--- Harry Sack [EMAIL PROTECTED] wrote:
2007/9/8, Josh Coalson [EMAIL PROTECTED]:
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
a fact :)
Harry
--
*From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On
Behalf Of *Harry Sack
*Sent:* Saturday, September 08, 2007 6:06 AM
*To:* Brian Willoughby
*Cc:* flac-dev@xiph.org
*Subject:* Re: [Flac-dev] Re: multiple core support
2007/9/8, Brian
2007/9/8, Josh Coalson [EMAIL PROTECTED]:
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
Harry,
You assume that the only way to use FLAC is the way that you are
using it, by converting one file format to another. That's not the
only way to use FLAC. The most important uses of FLAC are for
internet streaming radio or hand-held digital audio players. Both of
these prominent
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
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
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.
--
avuton
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
___
it's really not complicated I think: only api changes to write on any
position in the file if that's not possible already with existing
function.
I'm not sure if decoding can have multi-core support: you need an api
for writing pcm files in different parts then and this is maybe more
difficult to
Hmm,
You're actually correct, when you put it that way. Because the audio
blocks are coded independently, you could speed things by having the
encoder (or decoder) do a little up-front processing on the metadata,
then use the overall settings to divide the file into sections and
run the