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

2007-09-10 Thread Harry Sack
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

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

2007-09-09 Thread Harry Sack
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

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

2007-09-09 Thread Harry Sack
2007/9/8, Brian Willoughby [EMAIL PROTECTED]: 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

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

2007-09-08 Thread Harry Sack
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

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

2007-09-08 Thread Harry Sack
2007/9/8, Brian Willoughby [EMAIL PROTECTED]: 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

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

2007-09-08 Thread Scot Thompson
@xiph.org Subject: Re: [Flac-dev] Re: multiple core support 2007/9/8, Brian Willoughby [EMAIL PROTECTED]: 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

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

2007-09-08 Thread Brian Willoughby
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

[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

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

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

2007-09-06 Thread Avuton Olrich
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. ___

[Flac-dev] Re: multiple core support

2007-09-06 Thread Harry Sack
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

[Flac-dev] Re: multiple core support

2007-09-06 Thread Brian Willoughby
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