[MPlayer-dev-eng] New audio and mixer interface, and old audio plugins

[D Richard Felker III]

On Sat, Jan 18, 2003 at 01:52:29PM +0800, Anders Johansson wrote:
> Hi,
> 
> I have started to remove the old audio plugins in my tree, found it a
> bit tricky because of the dependencies with the GUI. I guess I need to
> write the new interface before the old one is removed.
> 
> I started with the volume control, and found that there needs to be
> some sort of reporting of the audio capabilities for the whole thing

BTW, can we make the default volume scaling 0dB (no change) instead of
the current -10? I can't se how it's possibly useful to do -10 by
default since 90% of movies already have their sound inaudibly soft
anyway...

Also I have some ideas for speeding up the volume filter a lot and
supporting more features like soft clipping in the integer code. Is it
ok to commit stuff to libaf or do you want to take care of all the
changes for now?

> to work nicely. When I dug around I also found an audio input
> interface is starting to be built up. IMHO we should have one
> interface to the audio that supports both input and output for
> multiple audio devices (like audio out to two sound-cards, a network
> connection and file at the same time).

How does this work when the cards don't have a common clock source?
Will mplayer use one as a master clock source while the filter layer
controls the other and dynamically warps audio?

> Also, I need some help deciding one thing:
> I am planning to extend the interface to the mixer to giv a more
> simple interface to libaf than trying to manage dynamically added and
> removed filters, there are two ways to do it: 
> 
> 1. Maintain a list of desired order of the audio filters and insert
>    and remove filters according to that list. If the user specified
>    filter list differs from the specified order it will either be
>    overridden or things will stop working.
> 
> 2. Add filters dynamically according to some rule based system
>    (implemented in libaf), and try to use the filter order specified
>    by the user.
> 
> I guess 1. is easier to implement and will not fail very often, but
> 2. gives more flexibility but is more likely to give "strange" errors
> and bugs.
> 
> Anyone have a better idea, otherwise I'll go for 2.?

I'm not quite sure what you mean by all this. Where is the filter
order specified by the user? IMHO -af should force a specific chain of
filters to be loaded, just like -vop does for video; if there's going
to be some sort of config for filter order preference on dynamic
insertion, it should be separate. Or, perhaps you could just have all
the filters in -af but have controls to turn them on/off?

One other idea, and this could apply to video filters too... It'd be
nice to have a way of specifying default filters that always get used,
in addition to ones specified on the command line. For example I
imagine dxr3 users always want -vop lavc at the end of their chain,
and users with yv12-impaired cards might always want -vop yuy2 at the
end. Similarly someone might always want to have the surround filter
loaded, and not have to manually specify it every time when using
other filters on the commandline.

> Also is it desirable to be able to instancify multiple mixers?

IMHO yes, all filter modules should be reentrant and support multiple
instances.

Rich