it actually is complicated. the libFLAC api is not suited to a multithreaded design because the i/o is stream-based, not file- based. flac(.exe) is the file-based wrapper around libFLAC that allows it to work on files. the way libFLAC buffers data is also impossible to parallelize without significantly changing the api. it would take a specialty file-based encoder using an independent frame encoder to do and even that is not trivial. --- Harry Sack <tranzedude@gmail.com> wrote:> 2007/9/7, Avuton Olrich <avuton@gmail.com>: > > > > On 9/6/07, Harry Sack <tranzedude@gmail.com> wrote: > > > it's really not complicated I think: only api changes to write on > any > > > > Please get started writing a patch, immediately. > > > > I'm just an IT student and I have no time for that :) > I also didn't study the flac API in detail but I know it's perfectly > possible because I made a avi encoder running on multiple threads > once and > it's exactly the same for audio data. > > -- > > avuton > > -- > > Anyone who quotes me in their sig is an idiot. -- Rusty Russell. > > > > _______________________________________________ > Flac-dev mailing list > Flac-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev >____________________________________________________________________________________ Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. http://smallbusiness.yahoo.com/webhosting
On Fri, Sep 07, 2007 at 04:59:50PM -0700, Josh Coalson wrote:> it actually is complicated. the libFLAC api is not suited to a > multithreaded design because the i/o is stream-based, not file- > based. flac(.exe) is the file-based wrapper around libFLAC that > allows it to work on files. the way libFLAC buffers data is also > impossible to parallelize without significantly changing the api.It seems like buffering (especially compressed) blocks and writing them to the stream in sequence wouldn't be a problem. Is there something in the way the blocking decisions are made that makes it hard to divide the input audio this way? -r
Ralph, The problem is that there is no clear advantage, at least in terms of multiple cores, to the approach you're asking about. In order to allow each stage of the codec to overlap, you need smart buffering between each stage. That adds code and complexity which isn't there currently. So you end up making the system do more work in the hopes that there will be some overlap. Basically, later stages get blocked waiting for their input buffer to fill, which means that you're not really getting very much overlap at all, but plenty of multi- threading overhead. At least that's the predicted result - I admit that nobody has tried this, to my knowledge. Brian Willoughby Sound Consulting On Sep 7, 2007, at 18:25, Ralph Giles wrote: On Fri, Sep 07, 2007 at 04:59:50PM -0700, Josh Coalson wrote:> it actually is complicated. the libFLAC api is not suited to a > multithreaded design because the i/o is stream-based, not file- > based. flac(.exe) is the file-based wrapper around libFLAC that > allows it to work on files. the way libFLAC buffers data is also > impossible to parallelize without significantly changing the api.It seems like buffering (especially compressed) blocks and writing them to the stream in sequence wouldn't be a problem. Is there something in the way the blocking decisions are made that makes it hard to divide the input audio this way? -r
2007/9/8, Josh Coalson <xflac@yahoo.com>:> > it actually is complicated. the libFLAC api is not suited to a > multithreaded design because the i/o is stream-based, not file- > based. flac(.exe) is the file-based wrapper around libFLAC that > allows it to work on files. the way libFLAC buffers data is also > impossible to parallelize without significantly changing the api.why was this approach used? The API design seems to me not very smart because it's not flexible and you're stuck in the future (like now for multiple core support) I don't see any reason why you wouldn't make it all based on files and not on streams :s It's just a major disavantage in my opinion it would take a specialty file-based encoder using an independent> frame encoder to do and even that is not trivial.so we can assume that those API changes will never come and the flac encoder will never have multiple core support? thx --- Harry Sack <tranzedude@gmail.com> wrote:> > > 2007/9/7, Avuton Olrich <avuton@gmail.com>: > > > > > > On 9/6/07, Harry Sack <tranzedude@gmail.com> wrote: > > > > it's really not complicated I think: only api changes to write on > > any > > > > > > Please get started writing a patch, immediately. > > > > > > > > I'm just an IT student and I have no time for that :) > > I also didn't study the flac API in detail but I know it's perfectly > > possible because I made a avi encoder running on multiple threads > > once and > > it's exactly the same for audio data. > > > > -- > > > avuton > > > -- > > > Anyone who quotes me in their sig is an idiot. -- Rusty Russell. > > > > > > _______________________________________________ > > Flac-dev mailing list > > Flac-dev@xiph.org > > http://lists.xiph.org/mailman/listinfo/flac-dev > > > > > > > > ____________________________________________________________________________________ > Building a website is a piece of cake. Yahoo! Small Business gives you all > the tools to get online. > http://smallbusiness.yahoo.com/webhosting > _______________________________________________ > Flac-dev mailing list > Flac-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20070908/1348d81b/attachment.html
Harry, You assume that the only way to use FLAC is the way that you are using it, by converting one file format to another. That's not the only way to use FLAC. The most important uses of FLAC are for internet streaming radio or hand-held digital audio players. Both of these prominent uses are not really file based, but are stream based. It makes perfect sense for the core of FLAC to be stream based. It makes the code small and portable to any platform, no matter how limited. Besides, the API has support for seekable streams and files. The big issue here is that you actually believe it is possible to support multiple processors and, further, that there would be an advantage to this. Those are both really big assumptions. I don't think anyone else, besides you, believes that it is possible or desirable for the FLAC codec to be multithreaded. Harry, you've sent 90 to 100 messages to these mailing lists asking about whether FLAC supports every possible feature that a given piece of software or an audio format could have. If you read about a feature someone else, you come here asking when FLAC will support that feature, or why not, without any idea of why it would even be good, or even possible. You don't seem to understand that it is not possible to put every feature into every program, not just because of development resource constraints, but also because certain features are mutually exclusive. Certain features make other features impossible, or at least undesirable. It simply isn't possible to do some of the things you're asking for, and I am actually surprised that you don't understand why they are impossible. You have basically shown a lack of solid understanding of formats, mathematics, programming, and logic. There is a popular saying: "The is no such thing as a stupid question." Well, Harry, you're the first person I've experienced who thoroughly challenges that statement. Brian W. On Sep 8, 2007, at 06:02, Harry Sack wrote: 2007/9/8, Josh Coalson <xflac@yahoo.com>: it actually is complicated. the libFLAC api is not suited to a multithreaded design because the i/o is stream-based, not file- based. flac(.exe) is the file-based wrapper around libFLAC that allows it to work on files. the way libFLAC buffers data is also impossible to parallelize without significantly changing the api. why was this approach used? The API design seems to me not very smart because it's not flexible and you're stuck in the future (like now for multiple core support) I don't see any reason why you wouldn't make it all based on files and not on streams :s It's just a major disavantage in my opinion it would take a specialty file-based encoder using an independent frame encoder to do and even that is not trivial. so we can assume that those API changes will never come and the flac encoder will never have multiple core support? thx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20070908/979f0b55/attachment.html
--- Harry Sack <tranzedude@gmail.com> wrote:> 2007/9/8, Josh Coalson <xflac@yahoo.com>: > > > > it actually is complicated. the libFLAC api is not suited to a > > multithreaded design because the i/o is stream-based, not file- > > based. flac(.exe) is the file-based wrapper around libFLAC that > > allows it to work on files. the way libFLAC buffers data is also > > impossible to parallelize without significantly changing the api. > > why was this approach used?because the tradeoffs I described required for arbitrarily parallel encoding significantly complicate the api and implementation. libFLAC was not design for multicode file encoding on PCs, it is a reference design that is also being used in embedded devices running <100MHz, low memory, all kinds of different OSes, etc.> The API design seems to me not very smart > because it's not flexible and you're stuck in the future (like now > for multiple core support) > > I don't see any reason why you wouldn't make it all based on files > and not on streams :s It's just a major disavantage in my opinionan api cannot be all things to everyone. you keep making this assertion but if you actually tried to implement it (and I hope you will) the problems we are all bringing up will quickly become obvious. your own lame-mt example is not an incremental improvement but a significant rewrite of lame (and also does not have nearly the performance advantage of process-level parallelism, see http://www.hydrogenaudio.org/forums/index.php?showtopic=50862)> > it would take a specialty file-based encoder using an independent > > frame encoder to do and even that is not trivial. > > so we can assume that those API changes will never come and the flac > encoder will never have multiple core support?you can assume libFLAC will probably not have it. if you can modify libFLAC to make a multithreaded encoder like flac-mt that would be neat and probably useful to some people. until that time there is not much point repeating the same assertions which are just going to aggravate people. Josh ____________________________________________________________________________________ Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. http://smallbusiness.yahoo.com/webhosting
--- Ralph Giles <giles@xiph.org> wrote:> On Fri, Sep 07, 2007 at 04:59:50PM -0700, Josh Coalson wrote: > > > it actually is complicated. the libFLAC api is not suited to a > > multithreaded design because the i/o is stream-based, not file- > > based. flac(.exe) is the file-based wrapper around libFLAC that > > allows it to work on files. the way libFLAC buffers data is also > > impossible to parallelize without significantly changing the api. > > It seems like buffering (especially compressed) blocks and writing > them > to the stream in sequence wouldn't be a problem. Is there something > in > the way the blocking decisions are made that makes it hard to divide > the > input audio this way?if the constraint of sequential output is kept, I was thinking that to get maximum efficiency, the library would need to be able to get samples out of order to keep all the threads going at max speed, or might have to grow buffers arbitrarily large if fed samples sequentially because of the different processing requirements of different blocks. extreme example: a block that goes through high- order LPC processing followed by several silence or noise blocks. Josh ____________________________________________________________________________________ Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC