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 files already. Tweaking this to support multi-threaded writes would not be too difficult. It's simply a matter of building the PCM file, setting aside the data area for the PCM samples, and then providing each thread with information needed to write at different offsets. FLAC never needs to "check for valid PCM streams" since it is creating the PCM stream from scratch every time.

Recording always involves a PCM data buffer. You're correct that there might be a 2 CPU split, automatically, depending upon the system. However, I was simply stating that going to an arbitrary number of threads would not be possible when recording, since you're only getting one block at a time, and the block is where the division between CPUs would be made.

Brian W.


On Sep 6, 2007, at 17:24, Harry Sack wrote:

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 check if it's valid pcm data since the decoder can only
check for valid flac streams , not pcm streams i think.

you can make recording also support multi cores: just let cpu 1 fill a
pcm data buffer while cpu 2 encodes it. In this case you have a more
reliable encoding with less cpu usage of your system (it's spread
among 2 cpu's)


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

Reply via email to