<br><br><div><span class="gmail_quote">2007/9/8, Scot Thompson <<a href="mailto:scot.thompson@cox.net">scot.thompson@cox.net</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial" size="2">No, streams should stay. Audio is NOT a file based
process -- it's a stream. You can't listen to an entire song
simultaneously. You organize it into files for later use, but you listen
and record from a stream. Stream-based storage is practically REQUIRED for
an audio codec. It's not random access, it's sequential. You can put
wrappers around it to make it convenient for file storage and conversions, but
the codec itself must be streams.</font></span></div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial" size="2"></font></span> </div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial" size="2">Multi-core support may not be practical for a
variable-length encoding. How would you know where to write the next block
when you don't know what size the first block is going to be? The
functionality for that is not trivial and is not currently implemented in the
API.</font></span></div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial" size="2"></font></span> </div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial" size="2">Maybe somebody will write a multi-core file-based wrapper
for you, or maybe you could try writing one yourself. Or if you disagree
with Josh about the direction of FLAC you can write your own codec. But
your nattering on and on about how you think the API isn't right doesn't help at
all and is very annoying.</font></span></div></div></blockquote><div><br><br>I just say that the way it is now it's IMpossible to make multiple core support, that's all. It's just a fact :)<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;"><div><div dir="ltr" align="left" lang="en-us"><hr>
<font face="Tahoma" size="2"><b>From:</b> <a href="mailto:flac-dev-bounces@xiph.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">flac-dev-bounces@xiph.org</a>
[mailto:<a href="mailto:flac-dev-bounces@xiph.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">flac-dev-bounces@xiph.org</a>] <b>On Behalf Of </b>Harry
Sack<br><b>Sent:</b> Saturday, September 08, 2007 6:06 AM<br><b>To:</b> Brian
Willoughby<br><b>Cc:</b> <a href="mailto:flac-dev@xiph.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">flac-dev@xiph.org</a><br><b>Subject:</b> Re: [Flac-dev] Re:
multiple core support<br></font><br></div>
<div></div><br><br>
<div><span class="gmail_quote">2007/9/8, Brian Willoughby <<a href="mailto:brianw@sounds.wa.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">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" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">Flac-dev@xiph.org</a><br><a href="http://lists.xiph.org/mailman/listinfo/flac-dev" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://lists.xiph.org/mailman/listinfo/flac-dev</a><br></blockquote></div><br></div>
<br>_______________________________________________<br>Flac-dev mailing list<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:Flac-dev@xiph.org">Flac-dev@xiph.org</a><br><a onclick="return top.js.OpenExtLink(window,event,this)" href="http://lists.xiph.org/mailman/listinfo/flac-dev" target="_blank">
http://lists.xiph.org/mailman/listinfo/flac-dev</a><br><br></blockquote></div><br>