[Flac-dev] Re: multiple core support

[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 <xflac at yahoo.com>:
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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20070908/979f0b55/attachment.html