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

[D Richard Felker III]

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.

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

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

Rich