Greetings!
At 30 Dec 2004 22:59 GMT,
Post by Jens LippmannHello 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
Post by Jens LippmannI currently use libmad 0.15.1b to stream MP3 files
into WAV sound buffers and I need to improve the
performance.
benchmark, benchmark, benchmark.
Post by Jens LippmannThe mere task of streaming a single audio file
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!
Post by Jens LippmannSo, 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
Post by Jens Lippmannkind regards
Jens Lippmann