[MPlayer-dev-eng] Moving the audio plugins to libmpcodecs - design of plugin management

[Anders Johansson]

Hi,

> On Tue, Jun 18, 2002 at 02:46:54PM +0800, Anders Johansson wrote:
> > 1. Poor SNR (signal to noise ratio) cause quantization noise is
> > accumulated in the plugins.
> > 2. Almost impossible to write filters that don't have problems with
> > fixed point overflow (to get around they have to use scaling which ads
> > noise)
> > 3. Quantization in filter-taps makes it very hard to design feedback
> > structures that are stable (thats why it took me s long to finish the
> > EQ) and again it ads necessary scaling and thus noise. An example is
> > the EQ i have written reduces the SNR from 96dB (which is what you get
> > from int16) to 69dB (which is clearly audible) and there is nothing I
> > can do about it.
> 
> I understand that it's not optimal for these kinds of plugins, but I
> couldn't really care less about eq. I just want resampling to exactly
> 44100, working software volume control (not too important), and maybe
> volume normalization now and then. I'm sure they could all be done
> slightly better in floating point, but if the movie plays at 10 fps
> while they're enabled it doesn't do much good.

There is already a fix point implementation of all the plugins you
mention above. I will port all of them (except for volume
normalization the person who wrote it will have to do it himself) to
the new plugin system and after that I will rewrite them in floating
point. Based on preformace measurements we can then write
recomendations to future plugin developers. 

> > I do believe however that we need fix-point stuff for a while (another
> > couple of years) for the sake of speed. 
> 
> Still no point in removing it after then, just don't support it for
> new plugins.

Time will tell :).

> > The reason I want to reduce the number of formats is to make it easier
> > to write new plugins and to reduce user complaints. One reason for the
> > current structure to suck is that there are too many formats. And
> > asking the plugin writers to support all formats is not an option,
> > what happens is what we have now, only int16 le is supported (except
> > for the volume and format plugins) cause it is the most common
> > one. With only one format it is possible to concentrate on that one and
> > optimize for it. Also I have noticed that the audio plugins take so
> > little processor power that optimization almost is becomes
> > unnecessary, so the gain of having more than one fix point format is
> > negligible.
> > 
> > > > The effect plugins are runtime pluggable and user selected, many of
> > > > them has GUI. Store in a linked list and must be able to adopt to
> > > 
> > > Bleh, I hope they're also nice and functional without gui...
> > 
> > I should have said OSD or GUI. Some plugins becomes a bit hard to use
> > without visual feedback like for example EQ and multi channel volume.
> 
> I agree it's nice, but there should also be plain old -aop
> eq=opt1:opt2:... for noninteractive use.
> 
> > > > changes in the data stream. This is one of my problems how should they
> > > > be initialized? One idea is to not have any init function by probe the
> > > > data stream in the run function when they are called and reinitialized
> > > > if necessary. Please advise me on this one.
> > > 
> > > Probably use a config() call like vo/vop. Just make sure it's safe to
> > > be called multiple times, unlike in most of the vo drivers.
> > 
> > Do you mean something like configure(AOPLUGIN_REINIT,new_config), I
> > have thought of this solution but I am not sure it is the best.
> 
> It seems workable as long as it propegates through the chain right
> when necessary. Of course it's probably best to listen to what Arpi
> has to say about it.

I'll write some code based on above plus what A'rpi said. I would
prefer to buffer the data in only one point in the system. I think
that would aviod many of the poblems we have had with the current
double buffering system.

> Rich

//Anders