<br><br><div><span class="gmail_quote">2007/9/9, Josh Coalson &lt;<a href="mailto:xflac@yahoo.com">xflac@yahoo.com</a>&gt;:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
--- Harry Sack &lt;<a href="mailto:tranzedude@gmail.com">tranzedude@gmail.com</a>&gt; wrote:<br>&gt; 2007/9/8, Josh Coalson &lt;<a href="mailto:xflac@yahoo.com">xflac@yahoo.com</a>&gt;:<br>&gt; &gt;<br>&gt; &gt; it actually is complicated.&nbsp;&nbsp;the libFLAC api is not suited to a
<br>&gt; &gt; multithreaded design because the i/o is stream-based, not file-<br>&gt; &gt; based.&nbsp;&nbsp;flac(.exe) is the file-based wrapper around libFLAC that<br>&gt; &gt; allows it to work on files.&nbsp;&nbsp;the way libFLAC buffers data is also
<br>&gt; &gt; impossible to parallelize without significantly changing the api.<br>&gt;<br>&gt; why was this approach used?<br><br>because the tradeoffs I described required for arbitrarily parallel<br>encoding significantly complicate the api and implementation.
<br>libFLAC was not design for multicode file encoding on PCs, it is a<br>reference design that is also being used in embedded devices running<br>&lt;100MHz, low memory, all kinds of different OSes, etc.</blockquote><div>
<br><br>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&#39;s with multiple cpu&#39;s and stream based code for all other devices and streaming :)
<br>Then you have both in the API! <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;">&gt; The API design seems to me not very smart
<br>&gt; because it&#39;s not flexible and you&#39;re stuck in the future (like now<br>&gt; for multiple core support)<br>&gt;<br>&gt; I don&#39;t see any reason why you wouldn&#39;t make it all based on files<br>&gt; and not on streams :s It&#39;s just a major disavantage in my opinion
<br><br>an api cannot be all things to everyone.&nbsp;&nbsp;</blockquote><div><br><br>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 <br>
</div><br><div><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;">you keep making this<br>assertion but if you actually tried to implement it (and I hope
<br>you will) the problems we are all bringing up will quickly become<br>obvious.<br><br>your own lame-mt example is not an incremental improvement but a<br>significant rewrite of lame (and also does not have nearly the<br>
performance advantage of process-level parallelism, see<br><a href="http://www.hydrogenaudio.org/forums/index.php?showtopic=50862">http://www.hydrogenaudio.org/forums/index.php?showtopic=50862</a>)</blockquote><div><br>It&#39;s multi-threaded and that&#39;s what I mean: people here say an audio codec can&#39;t be written multi-threaded and it will give no performance boost:
<br>1) that&#39;s false: se LAME MT<br>2) performance boost up to 30%: see LAME MT again<br><br>For very large files you must wait not so long before it&#39;s encoded vs. the original LAME. <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;">
&gt; &gt; it would take a specialty file-based encoder using an independent<br>&gt; &gt; frame encoder to do and even that is not trivial.<br>&gt;<br>&gt; so we can assume that those API changes will never come and the flac
<br>&gt; encoder will never have multiple core support?<br><br>you can assume libFLAC will probably not have it.&nbsp;&nbsp;if you can modify<br>libFLAC to make a multithreaded encoder like flac-mt that would be<br>neat and probably useful to some people.&nbsp;&nbsp;until that time there is
<br>not much point repeating the same assertions which are just going to<br>aggravate people.<br><br>Josh<br><br><br><br><br>____________________________________________________________________________________<br>Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online.
<br><a href="http://smallbusiness.yahoo.com/webhosting">http://smallbusiness.yahoo.com/webhosting</a><br></blockquote></div><br>