Re: S: faster decoder than libmad

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
> 
> 
> 
>