On 04-Apr-2000 Rob Leslie wrote:
So, I see comments to the effect of "need some n-bit type here", "depend on <type> being n-bits", etc. Is there a reason you did not use the int32_t and what not types? They are part of the new C standard, so will be portable.
There are only a very few places where I make assumptions about type length, and this is largely due to haste more than anything. These places are marked so I (or you :-) can fix them.
would a s/long long/int64_t/g patch be accepted then?
A bigger problem in my view with respect to portability are the places where I rely on sign-extending right-shifts, and the GCC extension I used to initialize members of the Huffman table unions. In time I'll fix these too.
well gcc is one of the most portable compilers around, depending on gcc is not that horrible. But yeah, it would probably be better to fix this as well.
Be careful not to confuse libmad with madplay; all (well, most) exported libmad symbols are indeed prefixed with mad_. The only exception I think is the fixed-point abstraction which uses f_ and the fixed_t type. (Perhaps these should also be prefixed with mad_?)
if it is exported in libmad.h (or seen in 3rd party code) it should have the mad_ prefix or some other library specifix prefix.
The other audio_* calls you see in madplay are not part of libmad; they're part of madplay's audio abstraction to support multiple output modules. A look through audio.h, audio.c, and audio_*.c should be instructive. Admittedly, madplay probably should not have defined its own audio_init() and audio_finish(). Sorry about that. :-)
perhaps the audio functions could get wrapped into their own lib as well? If I were to write a player based on this lib, I would likely use the audio routines as well. No sense recreating the wheel.
It might also have helped if I had put the libmad source strictly into a separate subdirectory, and I may eventually do this. For now, only what you see in libmad.h should be considered part of libmad.
Moving to subdirs would be a good idea.
/mad /decoder /audio /id3 (maybe) /player /docs
I don't have very much experience programming DSPs so I don't know. Anyone?
As I see it, if a dsp exists, it does all the math. So it should simply be possible to do: stream -> dsp -> synth / sound (depending on dsp). In the library it should simply choose not to do the hard work, bypassing most of the lib.
I was recently doing some performance tests to compare MAD against other fixed-point decoders I'm aware that also run under ARM. Here's what I found; this is the amount of CPU time required to decode a stereo MPEG stream in each of the audio layers as a percentage of audio real-time:
What do you use to create these numbers? I have simply been using top.
This doesn't tell the full story, though, as there are reports of splay decoding Layer III using as little as 4% of the CPU under a 280MHz SA-110 Netwinder while Xaudio and MAD still require 15-23%. This is quite a dramatic improvement for splay, and I'd love to see if MAD could likewise be optimized. (Hi Nicolas!)
4%? impressive. A SA-110 at 280mhz (I thought the netwinder was 275) is roughly a pentium 200.
How does mad compare in quality of output? My sound system here is rather weak, so I can not really hear the difference between say mpg123 and mad (if there is one).
Your docs mention the 'is' kluge. What files use is? None of my collection seems to sound different whether I have the kluge enabled or not.