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

[Vladimir Mosgalin]

Hi Reimar D?ffinger!

 On 2005.01.30 at 22:48:16 +0100, Reimar D?ffinger wrote next:

> > 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.
> 
> Your argument that libmad is eating a lot more probably is valid, but
> otherwise the standard for MPlayer is that an old PII should be able
> to play medium-res mp2 video, and mp3 should wotk flawlessly on a P90
> or less... If you have access to something like that ;-)

Well, there is my old P166 lying under the wardrobe, but it would be a
pain in ass compiling and linking for it, and I can't afford to install
more libraries there.
Maybe I'll try...

> > But really, this is bad solution. The real solution would be forcing all
> > mplayer's internal audio processing in 32-bit integers (with conversion
> 
> forcing no, supporting yes.

It's the matter of saying - but there is no reason to do processing in
16 bits at all.

> > 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
> 
> Now I know why mad is so slow! That scale function should not be there!
> Instead it should only support certain mad_fixed_t types and return them
> directly.

Eh? Mad gives high-quality output, so 32 bits are necessary. 16-bit
fixed point calculations for mp3 decoding just won't cut. It does it in
32 bits instead of doing it in floating point. And since internal
processing is 32 bit, it returns 32-bit data. 24 meaningful bits padded
to 32. And you can either round them to 16 or use dithering.

mad_fixed_t is always 32 bit, except for 64-bit systems, where it is 64
bit ;)

Of course, audio decoder should always return 32-bit integers directly.
As a matter or fact, all audio processing must honor this. And only one
dithering function, in the end of chain before output driver.

> [...]
> > 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?
> 
> They will be rounded where it is neccessary, i.e. before the first
> filter that doesn't support 32 bit - which currently means before any
> filter.

Converting some filters to 32 bits would be very easy, but won't it also
be rounded in general audio filters interface, i.e. before and/or after
filter chain?

If no audio filters are used, will be it rounded in output driver or
before that?

Also, where it is declared that audio filters don't support 32 bit? It's
not like "16" is defined somewhere inside or they are returning short
ints.

> > At present time, playback of 24-bit pcm wav file results in
> > Unknown/not supported internal format: s24le
> 
> This is a message from ao_oss, meaning that your soundcard does not
> support it (I recently changed it so it will only be displayed with -v).

Yes, at the moment it doesn't, but some do, and for audigy cards 24-bit
output will be supported in alsa, don't know how soon, but people are
working on it.

> > 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.
> 
> There is no reason for that... Can you provide a sample?

Hmm.. Do you have audacity? Open a wav file, select 32-bit float output
for wav in preferences and try to play the result (codec value will be
0x3).

-- 

Vladimir