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

Anders Johansson ajh at atri.curtin.edu.au
Tue Jun 18 06:58:03 CEST 2002


Hi,

I have continued my design on the new audio plugin layer (moving audio
plugins to libmpcodecs). I have also had a look at what other people
have done. There seems to be a move towards floating point processing
of sound. I believe this is a very good thing, and propose we do the
same. Below is a draft of the design plus a number of issues I would
like feedback on.


The sound data format (not the information itself) can be changed with
regards to the following aspects:
Sample Frequency
Bits per sample
Big/Little endian
Signed/Unsigned
Float/Integer
Special formats such as AC3 and MPEG audio
Number of channels


Design:
3 types of plugins input, effect and output.

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 
   1.2 Sample frequency conversion i.e. resampling (increase sample
       frequency on fast systems)

2. Effect plugins
   2.1 Equalizer
   2.2 Panning of listening position
   2.3 Room De-reverberation 
   2.4 Church effect (I have found some interesting scientific papers
       on this if anyone is interested in implementing it).
   2.5 Volume normalization
   2.6 Pitch scaler
   2.7 Surround sound plugin
   2.8 Simulated 4 ch stereo (3d effect)

3. Output plugins
   3.1 Volume control (multichannel with balance)
   3.2 Sample rate conversion if necessary 
   3.3 Format conversion (what ever the sound card requires)
   3.4 AC3 encoding 
   3.5 Channel duplication or truncation (i.e. if the user has
       specified 4 channels then copy or truncate number of channels 
       to fit 4).


The Input plugins are stored in a linked list and are auto-configured
at start of a new movie.

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

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.


An other issue is buffering and how to handle changes in buffer size.
One idea I have had is to reallocate buffers when necessary. The
potential bugs this could lead to could be solved by supplying a
standardized memory management library to the plugin writers (i.e. a
function to realloc buffers). Problem with this approach is that the
buffering in mplayer has to be changed a bit to accommodate dynamic
buffer size.  Second best solution wold be to have double buffering
like I solved it in the old plugin manager, but IMOH that is a bad
idea. Please help me with this.


An other issue is AC3 - personally I want to have AC3 pass-through and
never touch the data stream, same goes for MPEG audio.

Also do we want closed source plugins to be loadable like they are in
xmms? I guess no???


I have scraped my previous design (I had a preliminary one) and
started over a bit. Please give me your thoughts on the above issues,
I want the new design to be less buggy (and hopefully final :) than the
current one.


Best regards,
//Anders



More information about the MPlayer-dev-eng mailing list