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 FLAC process in parallel. However, I think it is generally frowned upon in some circles to create one thread per processor, rather than making the division dependent upon some other factor that is actually independent of the number of processors. Apart from that caveat, someone could certainly develop an encoder or decoder which uses the FLAC library API to implement a threaded encoder/decoder - well, assuming that the API can write to subsets of a file, instead of requiring that the entire file be written from start to finish - and also assuming that the API can run in multiple threads and write to the same file.

By your method, decoding would be faster, too. Not everybody decodes just to listen. Some of us keep original masters in FLAC format for archival purposes, but need the whole thing decoded before we can mix and master. Anything which speeds up decoding would help get work done faster.

On the flip side, another thing to consider is that not all encoding is done with files that already exist. If you are recording live to FLAC, you cannot multi-thread the encoder because you don't have any audio besides the current block.

So, decoding for playback and encoding for recording are two examples which cannot be multi-threaded. But file format conversion could be developed to take advantage of multiple processors. It would require a lot of tweaks to the library, perhaps.

Note: PC games are multi-threaded because they're already doing several different things at once. Sometimes the complexity is actually reduced by dedicating a thread to each part of the game logic. And precisely because there are so many different things going on, multi-threading can speed things up when they overlap in unpredictable ways. Games would be harder to write in a single- threaded way. Meanwhile, encoding/decoding FLAC is easier to write in a single-threaded design.

Brian W.

On Sep 6, 2007, at 16:42, Harry Sack wrote:

yes, i totally agree but I'm talking about the ENcoder :)
You can perfectly 'cut' the pcm stream 'in half' and let 1 cpu encode
one part , the other 2nd part (or with 4 cpu's in 4 parts, ...),
because it's just a stream one frame after the other,  as far as i
know (correct me if i'm wrong).
Many pc games synchronise multiple threads on 2 (even 4!) cores (much
More complicated then reading frames, compressing, writing compressed
frames like the encoder does), so i think making the encoder support 2
cpu's is perfectly possible.

of course adding multi-core support to the decoder is silly because
it's not necessary (any single core cpu is fast enough to play 1 file
and it would only slow it down)!

2007/9/7, Brian Willoughby <[EMAIL PROTECTED]>:
Any software which supports multiple processors must be multi-
threaded.  The process of designing multi-threaded code adds
complexity to the software, so there must be a good reason to go
through all the trouble.  The procedure for decoding a single file
could only benefit marginally from being multi-threaded, because most
operations would need to wait until the previous operation was
completed.  One section of the decoder might be able to process
several blocks, but the overall result would still need to wait until
all blocks are completed.  Besides, managing dynamic buffers between
each step of the decoding process would actually require the decoder
to do more, meaning it would slow down to an extent.  There would
pretty much be no difference in the total time, whether single
processor or multiple processors.

The best way to take advantage of multiple processors is to decode
multiple FLAC files at the same time.  This will take full advantage
of your system, provided that the disk bandwidth and memory bandwidth
can keep up.

Brian W.

Flac-dev mailing list

Reply via email to