On 18 Sep, Samuel Greear wrote:
> 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.
--
If Bill Gates had a dime for every time a Windows box crashed...
...Oh, wait a minute, he already does.
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7
--
MP3 ENCODER mailing list archive is at:
http://www.mail-archive.com/mp3encoder%40minnie.cs.adfa.edu.au/
