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 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.
 
  why was this approach used?

 because the tradeoffs I described required for arbitrarily parallel
 encoding significantly complicate the api and implementation.
 libFLAC was not design for multicode file encoding on PCs, it is a
 reference design that is also being used in embedded devices running
 100MHz, low memory, all kinds of different OSes, etc.



euh :) Just make a flag or something in the api that enables the code for
low cpu power devices and/or streaming and disable this when encoding on
fast pc (so no streaming)? So it uses file based code then for encoding of
files on pc's with multiple cpu's and stream based code for all other
devices and streaming :)
Then you have both in the API!

 The API design seems to me not very smart
  because it's not flexible and you're stuck in the future (like now
  for multiple core support)
 
  I don't see any reason why you wouldn't make it all based on files
  and not on streams :s It's just a major disavantage in my opinion

 an api cannot be all things to everyone.



sure it can: you just have to make some different cases (low cpu power
device/streaming or multi-core cpu) and call the apprioprate functions




you keep making this
 assertion but if you actually tried to implement it (and I hope
 you will) the problems we are all bringing up will quickly become
 obvious.

 your own lame-mt example is not an incremental improvement but a
 significant rewrite of lame (and also does not have nearly the
 performance advantage of process-level parallelism, see
 http://www.hydrogenaudio.org/forums/index.php?showtopic=50862)


It's multi-threaded and that's what I mean: people here say an audio codec
can't be written multi-threaded and it will give no performance boost:
1) that's false: se LAME MT
2) performance boost up to 30%: see LAME MT again

For very large files you must wait not so long before it's encoded vs. the
original LAME.

  it would take a specialty file-based encoder using an independent
   frame encoder to do and even that is not trivial.
 
  so we can assume that those API changes will never come and the flac
  encoder will never have multiple core support?

 you can assume libFLAC will probably not have it.  if you can modify
 libFLAC to make a multithreaded encoder like flac-mt that would be
 neat and probably useful to some people.  until that time there is
 not much point repeating the same assertions which are just going to
 aggravate people.

 Josh





 
 Building a website is a piece of cake. Yahoo! Small Business gives you all
 the tools to get online.
 http://smallbusiness.yahoo.com/webhosting

___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev


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

2007-09-09 Thread Harry Sack
2007/9/8, Scot Thompson [EMAIL PROTECTED]:

  No, streams should stay.  Audio is NOT a file based process -- it's a
 stream.  You can't listen to an entire song simultaneously.  You organize it
 into files for later use, but you listen and record from a stream.
 Stream-based storage is practically REQUIRED for an audio codec.  It's not
 random access, it's sequential.  You can put wrappers around it to make it
 convenient for file storage and conversions, but the codec itself must be
 streams.

 Multi-core support may not be practical for a variable-length encoding.
 How would you know where to write the next block when you don't know what
 size the first block is going to be?  The functionality for that is not
 trivial and is not currently implemented in the API.

 Maybe somebody will write a multi-core file-based wrapper for you, or
 maybe you could try writing one yourself.  Or if you disagree with Josh
 about the direction of FLAC you can write your own codec.  But your
 nattering on and on about how you think the API isn't right doesn't help at
 all and is very annoying.



I just say that the way it is now it's IMpossible to make multiple core
support, that's all. It's just 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 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 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.



 this is because of the limitations/design problem of FLAC API in
 particular. When the developers had made a smart decision and based
 everything on file based I/O you would get a HUGE performance boos when
 using multiple threads divided between multiple cores, because they only
 thing to do was to split the file output in different threads.
 But it's not clear to me why everything was based on streams...

 Harry

 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
 


 ___
 Flac-dev mailing list
 Flac-dev@xiph.org
 http://lists.xiph.org/mailman/listinfo/flac-dev


___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev


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 digital audio players.  Both of these prominent uses are not
 really file based, but are stream based.  It makes perfect sense for the
 core of FLAC to be stream based.  It makes the code small and portable to
 any platform, no matter how limited.



1) I never said this is the only way to use it: you put those words in my
mouth, I never told this to anybody :)
I also didn't say the fact that the API is based on streams is bad! I only
say it's not a good choice if you want to support multiple threads ...
Please read carefully what I write :)

Besides, the API has support for seekable streams and files.

 The big issue here is that you actually believe it is possible to support
 multiple processors and, further, that there would be an advantage to this.
 Those are both really big assumptions.  I don't think anyone else, besides
 you, believes that it is possible or desirable for the FLAC codec to be
 multithreaded.



2) you really show you have no good knowledge about programming. There are
several codecs out there that  try to use multiple cores.
To give a concrete example: http://www.lame-mt.com/
Here is the prove there is a HUGE performance boost:

'The output of this multi-threaded version, based on LAME 3.97 alpha, is 1:1
bit compatible with the original version and it gains *~1.16x speedup* when
Constant Bit Rate (CBR) or Average Bit Rate (ABR) models are used and *~1.30
speedup* when Variable Bit Rate (VBR) mode is used on SMT platforms and 
1.45x on SMP systems.'

If you say it can't have no speed improvement, then you prove you don't know
a thing about programming.
I will laugh at you when 8 cores wille be standard in all pc's and you still
will say the same :)

Harry, you've sent 90 to 100 messages to these mailing lists asking about
 whether FLAC supports every possible feature that a given piece of software
 or an audio format could have.  If you read about a feature someone else,
 you come here asking when FLAC will support that feature, or why not,
 without any idea of why it would even be good, or even possible.



3) I told you multiple thread support is possible, I gave you an real-life
example of the LAME encoder above.
I also gave reasons why it would be better: faster encoding speeds, ...
Besides that: you can't decide if I send messages to this list or not, so
don't *even* talk about that!



You don't seem to understand that it is not possible to put every feature
 into every program, not just because of development resource constraints,
 but also because certain features are mutually exclusive.  Certain features
 make other features impossible, or at least undesirable.  It simply isn't
 possible to do some of the things you're asking for, and I am actually
 surprised that you don't understand why they are impossible.  You have
 basically shown a lack of solid understanding of formats, mathematics,
 programming, and logic.



says the guy who tells me supporting multiple threads in the encoding phase
of an encoder is impossible and will give NO performance boost (I point you
out to LAME MT again that proves you're wrong) ...

There is a popular saying: The is no such thing as a stupid question.
 Well, Harry, you're the first person I've experienced who thoroughly
 challenges that statement.



And you are the first person who thinks he is mister-knows-it-all but gives
EXTREME funny and incorrect statements like:
- 'multiple core support won't give a performance boost'
- 'it's impossible to implement multiple threads in an audio encoder'

I recommend you to study IT (like I did) and get your master's degree and
after that maybe your PhD.
We'll talk again then when you accomplished this :)

best regards,
Harry

Brian W.


 On Sep 8, 2007, at 06:02, Harry Sack 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 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.



 why was this approach used? The API design seems to me not very smart
 because it's not flexible and you're stuck in the future (like now for
 multiple core support)
 I don't see any reason why you wouldn't make it all based on files and not
 on streams :s It's just a major disavantage in my opinion

 it would take a specialty file-based encoder using an independent
  frame encoder to do and even that is not trivial.



 so we can assume that those API changes will never come and the flac
 encoder will never have multiple core support?

 thx





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 is also
 impossible to parallelize without significantly changing the api.



why was this approach used? The API design seems to me not very smart
because it's not flexible and you're stuck in the future (like now for
multiple core support)
I don't see any reason why you wouldn't make it all based on files and not
on streams :s It's just a major disavantage in my opinion

it would take a specialty file-based encoder using an independent
 frame encoder to do and even that is not trivial.



so we can assume that those API changes will never come and the flac encoder
will never have multiple core support?

thx

--- Harry Sack [EMAIL PROTECTED] wrote:

  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 study the flac API in detail but I know it's perfectly
  possible because I made a avi encoder running on multiple threads
  once and
  it's exactly the same for audio data.
 
  --
   avuton
   --
   Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
  
   ___
  Flac-dev mailing list
  Flac-dev@xiph.org
  http://lists.xiph.org/mailman/listinfo/flac-dev
 





 
 Building a website is a piece of cake. Yahoo! Small Business gives you all
 the tools to get online.
 http://smallbusiness.yahoo.com/webhosting
 ___
 Flac-dev mailing list
 Flac-dev@xiph.org
 http://lists.xiph.org/mailman/listinfo/flac-dev

___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev


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



this is because of the limitations/design problem of FLAC API in particular.
When the developers had made a smart decision and based everything on file
based I/O you would get a HUGE performance boos when using multiple threads
divided between multiple cores, because they only thing to do was to split
the file output in different threads.
But it's not clear to me why everything was based on streams...

Harry

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

___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev


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

2007-09-08 Thread Scot Thompson
No, streams should stay.  Audio is NOT a file based process -- it's a
stream.  You can't listen to an entire song simultaneously.  You organize it
into files for later use, but you listen and record from a stream.
Stream-based storage is practically REQUIRED for an audio codec.  It's not
random access, it's sequential.  You can put wrappers around it to make it
convenient for file storage and conversions, but the codec itself must be
streams.
 
Multi-core support may not be practical for a variable-length encoding.  How
would you know where to write the next block when you don't know what size
the first block is going to be?  The functionality for that is not trivial
and is not currently implemented in the API.
 
Maybe somebody will write a multi-core file-based wrapper for you, or maybe
you could try writing one yourself.  Or if you disagree with Josh about the
direction of FLAC you can write your own codec.  But your nattering on and
on about how you think the API isn't right doesn't help at all and is very
annoying.

  _  

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



this is because of the limitations/design problem of FLAC API in particular.
When the developers had made a smart decision and based everything on file
based I/O you would get a HUGE performance boos when using multiple threads
divided between multiple cores, because they only thing to do was to split
the file output in different threads. 
But it's not clear to me why everything was based on streams...

Harry



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



___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev


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 uses are not really file based, but are stream  
based.  It makes perfect sense for the core of FLAC to be stream  
based.  It makes the code small and portable to any platform, no  
matter how limited.


Besides, the API has support for seekable streams and files.

The big issue here is that you actually believe it is possible to  
support multiple processors and, further, that there would be an  
advantage to this.  Those are both really big assumptions.  I don't  
think anyone else, besides you, believes that it is possible or  
desirable for the FLAC codec to be multithreaded.


Harry, you've sent 90 to 100 messages to these mailing lists asking  
about whether FLAC supports every possible feature that a given piece  
of software or an audio format could have.  If you read about a  
feature someone else, you come here asking when FLAC will support  
that feature, or why not, without any idea of why it would even be  
good, or even possible.  You don't seem to understand that it is not  
possible to put every feature into every program, not just because of  
development resource constraints, but also because certain features  
are mutually exclusive.  Certain features make other features  
impossible, or at least undesirable.  It simply isn't possible to do  
some of the things you're asking for, and I am actually surprised  
that you don't understand why they are impossible.  You have  
basically shown a lack of solid understanding of formats,  
mathematics, programming, and logic.


There is a popular saying: The is no such thing as a stupid  
question.  Well, Harry, you're the first person I've experienced who  
thoroughly challenges that statement.


Brian W.


On Sep 8, 2007, at 06:02, Harry Sack 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 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.


why was this approach used? The API design seems to me not very smart  
because it's not flexible and you're stuck in the future (like now  
for multiple core support)
I don't see any reason why you wouldn't make it all based on files  
and not on streams :s It's just a major disavantage in my opinion


it would take a specialty file-based encoder using an independent
frame encoder to do and even that is not trivial.


so we can assume that those API changes will never come and the flac  
encoder will never have multiple core support?


thx



___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev


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 significantly changing the api.

it would take a specialty file-based encoder using an independent
frame encoder to do and even that is not trivial.

--- Harry Sack [EMAIL PROTECTED] wrote:

 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 study the flac API in detail but I know it's perfectly
 possible because I made a avi encoder running on multiple threads
 once and
 it's exactly the same for audio data.
 
 --
  avuton
  --
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
 
  ___
 Flac-dev mailing list
 Flac-dev@xiph.org
 http://lists.xiph.org/mailman/listinfo/flac-dev
 



   

Building a website is a piece of cake. Yahoo! Small Business gives you all the 
tools to get online.
http://smallbusiness.yahoo.com/webhosting 
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev


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


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


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 mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev