<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.6000.16525" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=796323515-08092007><FONT face=Arial
color=#0000ff 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 class=796323515-08092007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=796323515-08092007><FONT face=Arial
color=#0000ff 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 class=796323515-08092007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=796323515-08092007><FONT face=Arial
color=#0000ff 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><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> flac-dev-bounces@xiph.org
[mailto:flac-dev-bounces@xiph.org] <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> flac-dev@xiph.org<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">brianw@sounds.wa.com</A>>:</SPAN>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">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="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">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></BODY></HTML>