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
