<br><br><div><span class="gmail_quote">2007/9/8, 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;">
Ralph,<br><br>The problem is that there is no clear advantage, at least in terms of<br>multiple cores, to the approach you're asking about. In order to<br>allow each stage of the codec to overlap, you need smart buffering
<br>between each stage. That adds code and complexity which isn't there<br>currently. So you end up making the system do more work in the hopes<br>that there will be some overlap. Basically, later stages get blocked
<br>waiting for their input buffer to fill, which means that you're not<br>really getting very much overlap at all, but plenty of multi-<br>threading overhead. At least that's the predicted result - I admit<br>that nobody has tried this, to my knowledge.
</blockquote><div><br><br>this is because of the limitations/design problem of FLAC API in particular. When the developers had made a smart decision and based everything on file based I/O you would get a HUGE performance boos when using multiple threads divided between multiple cores, because they only thing to do was to split the file output in different threads.
<br>But it's not clear to me why everything was based on streams...<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 Willoughby<br>Sound Consulting<br><br><br>On Sep 7, 2007, at 18:25, Ralph Giles wrote:<br><br>On Fri, Sep 07, 2007 at 04:59:50PM -0700, Josh Coalson wrote:<br><br>> it actually is complicated. the libFLAC api is not suited to a
<br>> multithreaded design because the i/o is stream-based, not file-<br>> based. flac(.exe) is the file-based wrapper around libFLAC that<br>> allows it to work on files. the way libFLAC buffers data is also<br>
> impossible to parallelize without significantly changing the api.<br><br>It seems like buffering (especially compressed) blocks and writing them<br>to the stream in sequence wouldn't be a problem. Is there something in
<br>the way the blocking decisions are made that makes it hard to divide the<br>input audio this way?<br><br> -r<br><br>_______________________________________________<br>Flac-dev mailing list<br><a href="mailto:Flac-dev@xiph.org">
Flac-dev@xiph.org</a><br><a href="http://lists.xiph.org/mailman/listinfo/flac-dev">http://lists.xiph.org/mailman/listinfo/flac-dev</a><br></blockquote></div><br>