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

[Anders Johansson]

Hi,

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

This is a safety setting to make sure the user doesn't blow up his
stereo, to override use -af volume=0

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

I don't care much about integer processing, commit anything you want
as long as it doesn't brake anything else. If you plan to do any
changes to float stuff, then my only concern is that the dynamic range
shouldn't be affected, i.e look out for conversions and floating point
underflow, and stick to float not double.

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

One (or the rtc) device is used for the time base, and resampling is
used for compensation. The resample rate is adaptive, so if the clocks
drift the resample rate changes (as long as the changes are below 1Hz
it is not possible to hear). It will be a SRLL (Sample Rate Locked
Loop :)

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

On the command line.

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

I am talking about dynamic filter insertion and removal, i.e through
the user interface during playback.

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

What do you mean? The surround filter gets unloaded automatically if
it isn't needed, you can have it enabled always.

> > Also is it desirable to be able to instancify multiple mixers?
> 
> IMHO yes, all filter modules should be reentrant and support multiple
> instances.

Sorry, perhaps I wasn't very clear. I mean the mixer found in mixer.c,
thats where I will write the runtime interface to the audio filter
layer. It will sort of look (in terms of functionality) like the
interface found on a combined D/A and amplifier that are used along
with stand alone DVD players. Is it desirable to perhaps create
different interfaces to the audio filter layer and have them
dynamically loadable, or is it overkill, that is my question? This
will be applicable to mencoder as well where one perhaps will want one
mixer for each audio stream.

> Rich

//Anders