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.
___
