[MPlayer-dev-eng] Audio filter problems: af_format.c

[Juergen Keil]

Hi,

some problem with the new audio filter code:

in libaf/af_format.c there are several loops converting sample formats.
Some loops start counting from 0,  some start at 1, i.e. there is a mix
of 
   for(i=0;i<len;i++){ ... }
and
   for(i=1;i<len;i++){ ... }
   

I'd say all of these loops in af_format have to start counting from 0...




2nd problem:


In af_format.c we have this piece of code:

  // Switch to the correct endainess (again the problem with sun?)
  if((lf&END_MASK)!=LE){
    switch(cf&NBITS_MASK){
      ... change byte order in 'local' output buffer ...
    }
  }
  
It tests the 'endianess' of the 'local' output format,  and if it's not
the desired byte order,  it gets changed based on the sample size of the
input(!) data?  Shouldn't the switch use 'lf' instead of 'cf'?

    switch(lf&NBITS_MASK){
      ...
    }
   
   

3rd problem:


How is the audio filtering system supposed to work on big endian cpus?

As far as I remember, mplayer's audio decoders all output audio samples 
in native byte order;  some of mplayer's audio output modules accept
both big & little endian samples (alsa/oss) while others want native
byte order.

Looking at af_format.c,  the code always forces "little endian" format
before the format conversion and it seems to byte swap after the format
conversion once again, in case the format filter's output is supposed to 
be in big endian format.

Since af_format.c is 'computing' with the sample values (signed <-> unsigned,
changing the sample precision with shifts) it should operate on samples
converted to the cpu's native byte order.  Forcing everything to little
endian is wrong.

af_resample.c is 'computing' with sample values once again,  but this
module does not care about the byte order?

af_channels.c is just copying samples around, byte order of the samples
should not matter at this time -  until it starts converting stereo -> mono
using an average operation for example,  then we need native byte order in
af_channels.c, too.