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

[Anders Johansson]

Hi, 

I wrote the code.

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

Yes it is a bug I'll fix it later today, thanks for finding it.


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

Not sure I'll have a look. I have never been able to test this code
cause I haven't had access to any movies with BE sound. Nor any HW
with BE output. Do you have access to any such movies or hardware?


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

Yes, It was the best I could think of.

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

You are correct, do you feel like helping me fix this?

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

af_channels is finished. The type of operations you are talking about
will be handled by other filters. If af_channels would start mixing
the auto configuration would break. I have deliberately written it to
be endian and word length independent.

//Anders