Greetings!

At 30 Dec 2004 22:59 GMT, Jens Lippmann wrote:

Hello all!

I'm looking for a MP3 decoding lib faster than libmad, probably solely written in Intel assembler.

perhaps you might try compiling it with the intel compiler and see how that treats you

I currently use libmad 0.15.1b to stream MP3 files into WAV sound buffers and I need to improve the performance.

benchmark, benchmark, benchmark.

The mere task of streaming a single audio file saps about 11 milliseconds (@1.8GHz). libmad uses inline and asm here and there, but the costliest parts (frame decoding and synthing) are written in C, optimized for speed but still C.

i would assert that flinging assembly at a problem is rarely a good idea.

others are free to argue otherwise.

however, i'll raise what i think are 2 key points:

1. many language constructs compile directly into optimal asm constructs. that's why c and FORTRAN syntax look the way they do. it's also why lisp and FORTH look the way they do...but for a different reason.

2. compilers take the entire execution perspective into account when performing optimizations. they perform some pretty helpful analysis about variable lifetimes, register allocations, loop unrollings and other assorted deep-geek compiler guy buzzwords. think of it this way, when you run a compiler, the combined intellect of a zillion asm gods are busy 'hand optimizing' your code and in *most* cases, they/it are better at it than you are. :-)

3. sticking in 'hand tuned' assembly makes life really difficult for the compiler. when you do this, you break up the compilation units into smaller chunks and limit the compiler's effectiveness at global optimization. think about it, the compiler is forced to be very pessimistic(yup, that's a real compiler guy term, opposite of optimistic) because you have just hogged up a bunch of registers for your 'hot thang' and now the compiler has to assume that it will not be able to depend on those registers being available. so, your little hand tuned thing might run faster, but the overall perf might be worse because the compiler couldnt make accurate decisions about variable lifetimes so it decided *not* to do some optimizations.

4. Part of your issue may be with an insufficient understanding of where the pain points in compressing-codec decompression actually live. it's simply a math/load/store intensive process. simple as that. *all* DSP other than straight D/A PCM is computational expensive. you are trying to reconstitute the uncompressed .WAV from a compressed MP3. it's painful!

So, my question is if there's anything freely available that decodes faster than libmad?

you seem to understand on some level that this question might be disjoint from the asm implementation question, and i think that is a good thing.

you gotta code it, try it, and if it doesnt crash, benchmark it.

you *might* be right. a pure asm solution might be faster. but you wont know until you write it and test it and the NRE associated with that task might be better spent on a faster platform!...hmm, i'll go so far as to say *probably* better spent on a faster platform.

just my BSEE-DSP Musician Audiogeek Guy Who Used to Work at a Compiler Company Opinion....take it for the very little that it is worth in the absence of benchmarks. :-)

johnu

kind regards Jens Lippmann