[MPlayer-dev-eng] Dithering 16-bit output for libmad

[Vladimir Mosgalin]

Hi D Richard Felker III!

 On 2005.01.30 at 13:37:24 -0500, D Richard Felker III wrote next:

> I like this a lot in principle, but I'm concerned about performance
> still. Which cpus did you test this on, and how did you do the
> benchmarks? I would expect it might be a lot more of a problem on
> older ones with slow multiply, and it might make more of a difference
> when playing movies too (not just .mp3 files) if cache coherency is an
> issue and the extra code hurts cache performance.

One multiply per sample, 88000-96000 multipies per second won't hurt
much...

I tested it only on A64 3000+, which is pretty fast... I was going to
test it on PIII-500 in Monday, but after I got the results I thought it
wouldn't be neccessarry.

So, about the speed: mp3 decoding (30 minute 320kbit file, 44100hz, no
audio filters, oss driver, -nocache) with mp3lib takes 0.4-0.5% cpu
after minute of playback. The same file with mad: 1.1-1.2%. With mad &
lavcresample: 4.4-4.5%. This is in the beginning of file, it is much
less in the middle. With dithering on, the counters are the same.

Test that shows relatively speed:
mplayer -quiet test.mp3 -ao pcm:file=/dev/null:nowaveheader
was run 4 times. Without lavcresample, of course, since it would eat
most of cpu time otherwise, The average results were about 18.20-40
(forgot exact numbers) for rounding version and 19.30-40 for dithering
ones. The result I got was that dithering eats about 17 times less cpu
than libmad uses to decode the file. Since penalty drop from usage of
libmad and from lavcresample is much bigger, I think it's nothing.


But really, this is bad solution. The real solution would be forcing all
mplayer's internal audio processing in 32-bit integers (with conversion
to floats for filters that need it). It uses regular 32-bit ints in
filters anyway, but they are rounded to 16-bits in audio decoders and
possible some other places. This should happen only on output - for
example, in format filter, which would convert output to 16 bits either
with dithering or with rounding if the output doesn't support 24 bits.

I'd like to do something for this to happen, but I don't quite
understand details about mplayer's audio system, and can't even guess
how close it is to support full 32-bit processing (24 or 16-bit samples
padded to 32 bit, actually). For example, ad_libmad returns result as
16-bit data in ints, but what would happen if it would return full 32
bits of output? Will they be rounded to 16 bit in audio output driver or
before it?

At present time, playback of 24-bit pcm wav file results in
Unknown/not supported internal format: s24le
in mplayer's output, but it playbacks the file. The output is 16 bit,
and even -ao pcm writes 16-bit files, so I can't test whether 24 bits
would be rounded to 16. And mplayer doesn't play 32-bit files at all.

Is there anyone who can answer these questions and explain more about
audio system to me?

-- 

Vladimir