On May 24, 2011, at 12:11, David Troendle wrote: > Thanks for the tip, Brian. I did have a version that does > everything in > memory, but only had enough memory to get six threads going. > (Although my > system has 16GB, I have not taken the time to create 64-bit > libraries for > wxWidgets, TagLib, libFLAC, etc.)
What's wrong with only 6 threads? Is that just 3 FLAC recodes (3 decode, 3 encode)? With a queuing layer driving the threads, you could schedule hundreds of file recodes and each one would start as soon as a thread opens up. > Based on the direction you are pointing me in, I assume that > encoding from > within the decoder is not permitted. I have no idea. My assumption before your email would have been that the individual encoder/decoder handles would allow reentrancy, but perhaps there are pieces of libFLAC that are not reentrant even when working on separate encoder/decoder objects. The only way to know for sure is if Josh Coalson pipes up, or someone takes the time to look at the source for a thorough code review. There's a possibility that your code has a bug, and what you want to do may actually be possible. But, again, I have no idea. > I really like your idea of the FIFO, and will probably go in that > direction. > What do you think of implementing the FIFO via a pipe? That might > simplify > the implementation. You don't strictly need a FIFO. A pipe might be a good choice - at the very least it would allow you to link two processes instead of being limited to two threads within a process. The pipe could also allow you to decode on one machine and encode on another over a network connection - assuming that's of any use to you. Brian Willoughby Sound Consulting _______________________________________________ Flac-dev mailing list [email protected] http://lists.xiph.org/mailman/listinfo/flac-dev
