I made another significant improvement to MAD under ARM: using 64-bit multiply/accumulate instead of scaling after each multiply during synthesis, both performance and accuracy is increased.
The performance is increased so much, in fact, it is faster than using SSO.
I decided it was best to change the way MAD is configured, since individual options can now have unpredictable effects on performance and accuracy... instead of specifying SSO, ASO etc. explicitly, there are now three general options:
(the default) produce optimum accuracy and speed --enable-speed optimize for additional speed over accuracy --enable-accuracy optimize for additional accuracy over speed
The idea is to specify how to compromise between the two goals. The default is not to make any compromises, and deliver good accuracy with reasonable performance. Configuring with --enable-speed now automatically enables SSO, if that will make things faster. Likewise --enable-accuracy gets better accuracy wherever possible, at the expense of performance.
It turns out this doesn't make any difference now for FPM_ARM, but it does for FPM_64BIT and FPM_INTEL.
Andre's ARM code is now always enabled for ARM hosts, since it always improves both speed and performance; it must be explicitly disabled if not wanted.
Here's some updated statistics I measured with the new 0.11.3b:
(StrongARM 1100 220 MHz, accuracy and %CPU speed)
Layer I Layer II Layer III FPM_64BIT default 6.198e-8/F 20% 6.198e-8/F 20% 6.931e-8/F 29% FPM_64BIT OPT_SPEED 8.482e-6/F 17% 1.144e-5/L 18% 1.008e-5/L 26% FPM_64BIT OPT_ACCURACY 4.715e-8/F 25% 4.941e-8/F 24% 5.375e-8/F 33% FPM_APPROX * 7.880e-5/L 17% 6.627e-5/L 17% 6.431e-5/L 25% FPM_ARM * 4.667e-8/F 16% 4.906e-8/F 16% 5.338e-8/F 24%
/F means full compliance, /L means limited accuracy. Smaller numbers are better in all cases.
Using FPM_ARM is obviously a big win. :-)
By these numbers, MAD is now tied with Xaudio for Layer III decoding speed! Layer I and Layer II have been faster than Xaudio for some time, and in any case, MAD has always been much more accurate.
Get the new release here:
ftp://ftp.mars.org/pub/mpeg/
Cheers, -rob
I can no longer play mp3's on my laptop using the new mad release.
madplay ~/mp3/foo output: sample frequency 44100 Hz not available; closest 44191 Hz output: cannot resample 44100 Hz to 44191 Hz decode: error while decoding
this used be be a warning: output: sample frequency 44100 not available (closest 44191)
this is a x86 linux box running alsa for sound.
madplay ~/mp3/foo output: sample frequency 44100 Hz not available; closest 44191 Hz output: cannot resample 44100 Hz to 44191 Hz decode: error while decoding
I suppose this was made too strict. There should be some tolerance for sampling frequencies close to the requested one; I'll try to relax this.
Thanks, -rob
On 21-Sep-2000 Rob Leslie wrote:
madplay ~/mp3/foo output: sample frequency 44100 Hz not available; closest 44191 Hz output: cannot resample 44100 Hz to 44191 Hz decode: error while decoding
I suppose this was made too strict. There should be some tolerance for sampling frequencies close to the requested one; I'll try to relax this.
this happens with all the mp3's I tried. Can you explain what is happening? Is it a sound card / driver issue? Are my mp3's poorly encoded?
On Wed, 20 Sep 2000, Sean 'Shaleh' Perry wrote:
On 21-Sep-2000 Rob Leslie wrote:
madplay ~/mp3/foo output: sample frequency 44100 Hz not available; closest 44191 Hz output: cannot resample 44100 Hz to 44191 Hz decode: error while decoding
I suppose this was made too strict. There should be some tolerance for sampling frequencies close to the requested one; I'll try to relax this.
this happens with all the mp3's I tried. Can you explain what is happening? Is it a sound card / driver issue? Are my mp3's poorly encoded?
Some audio cards don't use a clock which perfectly result in a 44100Hz but pretty near that, and some drivers like to tell you when it happens (by returning the sampling rate that is the nearest from what is requested). This is not really a bug.
Now the latest madplay release includes a resampling function that tries to convert unsupported sampling rates to the one the card supports. For example, some audio cards may do 44100Hz but not 22050Hz. Since madplay has a strict resampling conversion which isn't able to do 44100Hz -> 44191Hz, it yield an error. In practice, the two are close enough so madplay could be told not to bother when the difference is small.
Nicolas