[MPlayer-dev-eng] af layer STILL broken

[D Richard Felker III]

On Tue, Jan 14, 2003 at 03:18:12PM +0800, Anders Johansson wrote:
> Hi,
> 
> > On Tue, Jan 14, 2003 at 10:54:33AM +0800, Anders Johansson wrote:
> > > Hi,
> > > 
> > > Sorry the patch brakes the decoding I get sig 11 in ad_libvorbis when
> > > using the patch (second tome decode_audio() is called). I found one
> > > bug which I fixed. I can't reproduce completely since I am running a
> > > alsa9 only system at the moment (statically linked kernel without
> > > oss emulation). I'll try it again when I get home. My guess is that ao_oss
> > > reports that it supports float even though it doesn't. alsa works qite
> > > well and detects the float, it doesn't support it however and returns
> > > uint8, which is correct but not good, and will need fixing.
> > > 
> > > Also the patch didn't apply cleanly.
> > 
> > Yes, that and the sig11 were caused by the fact that I applied several
> > bugfixes to the file after sending the patch to the list. Use CVS to
> > revert to the pre-fix version before applying the patch (the right
> > version number should be in the diff file) if you really want to test
> > it. But the concept should be straightforward.
> > 
> > And you're probably right that ao_oss is buggy here. But mplayer
> > shouldn't even be requesting float from the ao layer if I specify -af
> > format=2:signedintle, right??
> 
> Yes it should, this is a problem in the configuration of the whole
> system. It works like this:
> 
> 1. The audio decoder is selected and initialized.
> 
> 2. The audio output driver is selected and initialized depending on
> the requests from the audio decoder (sample rate, number of channels
> and sample format).
> 
> 3. The audio filter layer is initialized and it automatically
> compensates for differences between the audio decoder and the output
> driver. 
> 
> Hence, if you have enabled a format converter that isn't necessary it
> will be removed once the initialization gets to 3.

Ah, then now I understand how af differs from the video filter layer,
and how it should be changed (IMO):

1. Audio decoder should be selected and initialized.

2. Audio filters from the command line should be loaded and attached
   at the decoder end.

3. AO driver should be loaded and attached at the other end of the
   chain.

4. Audio decoder should begin querying the filter chain for supported
   formats. Depending on the filter it should either answer by itself
   (if it's a format conversion filter for example) or pass the query
   on down the filter chain (if it supports many different formats).
   Or in some cases it may do a combination. Whenever possible filters
   should avoid doing conversions to support more formats unless it
   can be done efficiently.

5. If there are problem points where steps of the chain are not
   compatible, filters should be inserted to fix the problem. Or
   perhaps only do this automatically at the beginning and end of the
   filter chain and require the user to manually resolve issues in the
   middle of it.

This is basically how the video filter layer works and it's a very
good model. IMHO the current audio handling model is very bad. It's
very difficult to generate good filter chains optimally suited to both
the capabilities of the AO device and the codec, and as I just found
it's impossible to explicitly design a chain, which is just nonsense!

Rich