> > Yeah, you're right. A simple test reveals the truth. I created a single > > lame_global_flags pointer for every thread rather than an individual one > > for each and used locking for it around lame_encode_buffer. The result > > is a happy sounding MP3. The performance, as expected, sucks.... > > With each encoder thread consuming ~50% of a CPU on a dual CPU > > box, again... as expected. I've just taken a look at how gogo does it > > and there doesn't appear to be too much involved, it's entirely > > concentrated in encodeframe(). When I get some more time I'll see if I > > can't merge gogo's pthread changes into encoder.c. > > You have to dissect the encoding into stages and let every stage run in > a seperate thread. Your solution should be in a way which didn't makes > threads (especally the thread library) mandatory (e.g. encapsulated > in > "#ifdef ALLOW_THREADS" or something like this) else we can't add it to > LAME. The number of threads should be a runtime option with a check for > the upper limit (number of stages which can be used in parallel). > > Don't worry about the configure magic, just provide patches to the > source. :-) > > Bye, > Alexander. After looking over the gogo code it seems that they have pretty much done away with lame_global_flags and lame_internal_flags, and after some toying it seems that this is pretty much the only way to get any real performance out of a threaded backend. Seeing as pretty much everything has its fingers into those global structures it looks to be no small task. If there's an elegant solution, I have yet to see it, and don't really have the time with work and all to undertake a major renovation of the library. If someone with intimate knowledge of the library came up with a plan of attack I'd be willing to help, however. Sam -- MP3 ENCODER mailing list archive is at: http://www.mail-archive.com/mp3encoder%40minnie.cs.adfa.edu.au/
