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

[Anders Johansson]

Hi,

> On Tue, Jun 18, 2002 at 12:58:03PM +0800, Anders Johansson wrote:
> > Design:
> > 3 types of plugins input, effect and output.
> 
> Hmm, why? Treating all the filters the same works fine for video; I
> don't see why it should be any different for audio...
> 
> > 1. Input plugins
> >    1.1 Format conversion always converts to one of the following:
> >        Signed 16 bit Little endian integer (for slow systems, will be
> >        removed in the future)
> >        Signed 32 bit Little endian Floating point 
> 
> Removing integer is silly, as is using little endian. Preferred sample
> format should be host byte order for maximum speed in 'effect
> plugins'. Ideally, however, most if not all plugins should accept
> input in all (common) formats so as not to hinder performance.
> 
> As for dumping integer, why?? It's much faster and for lots of
> plugins, processing samples as integers is perfectly fine.

Three reasons I wan to get rid of fixed point:
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 do believe however that we need fix-point stuff for a while (another
couple of years) for the sake of speed. 

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.

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

> > Output plugins reads the capabilities of the hardware during startup
> > and are always called in the same order. These plugins must also
> > auto-configure cause the data stream coming from the Effect plugins
> > can change.
> 
> Why not just do like video filters and auto-add a format-fixer plugin
> when the ao device can't handle the output format of the last plugin
> in the chain?

This was my first idea, but I discarded it in favor for only two
different formats, see above.

> > An other issue is AC3 - personally I want to have AC3 pass-through and
> > never touch the data stream, same goes for MPEG audio.
> 
> Sounds like it could be modelled directly after mpegpes in the vo
> system.
> 
> > Also do we want closed source plugins to be loadable like they are in
> > xmms? I guess no???
> 
> I would say no, but Arpi and others would probably eventually like it.
> This probably doesn't need to be core to the design though; instead,
> there could just be a special binary-loader aop filter that would load
> and interface with the particular binary filter types you want to
> support. For example, -aop xmmsplugin=blah.so:opt1:opt2:...

I think this is a very good idea, thanks.

> 
> 
> Rich

Cheers,
//Anders