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

[Reimar Döffinger]

Hi,
On Mon, Jan 31, 2005 at 12:20:11AM +0300, Vladimir Mosgalin wrote:
> 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 ;-)

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

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

[...]
> 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.

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

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

Greetings,
Reimar Döffinger