<br><br><div><span class="gmail_quote">2007/9/7, Brian Willoughby <<a href="mailto:brianw@sounds.wa.com">brianw@sounds.wa.com</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I really should have just said that it will require some testing to<br>make sure the FLAC API can handle writing the same file from multiple<br>threads. It may not turn out to be complicated at all.<br><br>The FLAC decoder has its own code for writing PCM files already.
<br>Tweaking this to support multi-threaded writes would not be too<br>difficult. It's simply a matter of building the PCM file, setting<br>aside the data area for the PCM samples, and then providing each<br>thread with information needed to write at different offsets. FLAC
<br>never needs to "check for valid PCM streams" since it is creating the<br>PCM stream from scratch every time.</blockquote><div><br><br>But it's not 100% lossless if you don't check it when written using different threads. Now there is only 1 thread that writes at the back of the file in a lineair way. So the chance there is an error when decoding is almost non existing because it just write the new block at the end of the file till it's finished.
<br><br>If you write the file in parts at different locations inside the pcm file on even different cpu's, there are certainly things that can go wrong. And you say there is no need to check those resulting pcm streams ... So this makes no sense: what if there was something wrong with 1 thread on 1 cpu (maybe a synchronisation problem, ...)? Then there would be missing pcm blocks or even corrupted ones (because they are written at different locations in the file while running different threads on differents cpu's). So making decoding to support multiple cores is not easy as it sounds. There really has to be a 'checking' phase at the end to verify if the pcm stream was build up correctly using the different threads. If you don't check here, you risk getting non-lossless stream because of missing/corrupted blocks and this is exactly what a lossless codec doesn't want!
<br><br>At the encoding end there you can automatically check the resulting flac file using the verify option. So after running the multiple threads on the pcm stream that results in the flac file, you just check that resulting flac file using verify to see if the md5 checksum matches. So if something went wrong in some thread and there were missing blocks/corrupted ones, you will get a different md5 and you know exactly something went wrong and you just repeat the encoding process till everything is correct. At the decoding end you can't see this when using multiple threads because there is no way to check if the pcm stream was built up correctly (at least: as far as I know)
<br><br><br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Recording always involves a PCM data buffer. You're correct that<br>
there might be a 2 CPU split, automatically, depending upon the<br>system. However, I was simply stating that going to an arbitrary<br>number of threads would not be possible when recording, since you're<br>only getting one block at a time, and the block is where the division
<br>between CPUs would be made.</blockquote><div><br><br>yes of course: but recording has nothing do to with the encoder itself. The recording part happens in other software. You just get raw pcm data to encode, just like when encoding an existing file. There is really no difference because you can let the recording software say write x blocks of pcm data and you just encode these using multiple threads to flac. So it's perfectly possible to do it here too, but it's not really needed. It's only useful for encoding existing files.
<br><br>Harry<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Brian W.<br><br><br>On Sep 6, 2007, at 17:24, Harry Sack wrote:<br>
<br>it's really not complicated I think: only api changes to write on any<br>position in the file if that's not possible already with existing<br>function.<br><br>I'm not sure if decoding can have multi-core support: you need an api
<br>for writing pcm files in different parts then and this is maybe more<br>difficult to check if it's valid pcm data since the decoder can only<br>check for valid flac streams , not pcm streams i think.<br><br>you can make recording also support multi cores: just let cpu 1 fill a
<br>pcm data buffer while cpu 2 encodes it. In this case you have a more<br>reliable encoding with less cpu usage of your system (it's spread<br>among 2 cpu's)<br><br><br></blockquote></div><br>