[MPlayer-dev-eng] About the future - libao2

[Anders Johansson]

Hi,

> NO! MPlayer has its advantages and very high stability because its singlethread design.
> I won't change this one.
I agree, wouldn't really improve anything anyway just cause overhead.

> > As I see it there are three ways to go: 
> > 
> > 1.1 Keep the control of the initialisation (interpretation of cmdline
> > switches and settings saved in file etc) inside mplayer and inform
> > libao2 of what mplayer is expecting of it. What I mean is that init
> > takes two structs one telling libao2 what it will get and the other
> > what the user wants, all switches and config file parameters are
> > decoded by mplayer.
> what is the first struct for?
Telling libao2 output format of audio codec. Like what the current interface does.

> btw struct for cmdline/cfgfile options is ok, i already have this idea for
> libvo2 to avoid lots of globals
Sounds good :)

> > 1.3 Let libao2 keep the control of the initialisation, meaning that
> > cmdline switches are passed on and libao (sort of like gcc is passing
> > on switches to as using the -W switch) is keeping and maintaining it's
> > own config file. This approach has the advantage that developers
> > doesn't need to make changes to the mplayer source when they want to
> > add sound features, which makes the source easier to maintain. It will
> > also be easier to write new sound stuff.
> what about subconfig? it's a new feature of config parser, used mainly for
> mencoder. this way modules/libs can have their own set of options, while
> the main parser does all checks and processing.
> I mean, you can define and fill a struct in libao3 core, make it global.
> cfg parser will have a subconfig line pointing to this struct, so it will
> parse libao options using this set. this way libao shouldn't care of cfg
> parsing, file paths etc while can be extendable without any change to
> mplayer.
Sounds very good lets go for this one! I don't love globas but I guess
it is because I was once a C-- programmer, suppose I will have to get
used to the idea (it is a bit hard though feels like undoing toilet
training).


> > 2. Runtime interface.
> > How to send commands to libao2 during execution (pause reset etc).
> > 
> > 1.1 Keep current interface and disallow it to expand. All extended
> > stuff needs to be done off line (when mplayer is not running). Good
> > don't need to change anything. If something needs to be changed it
> > will be made through the control() function.
> i vote to this one. it's the main design goal for libvo2 too.
> standard functions have their function in libao drivers, and all
> extras or primitive set/get/query thing have control().
> 
> > 1.2 Make some kind of pluggable command interface so that the new
> > features can hook on to events. Not fun to implement and might cause
> > some runtime overhead.
> no...
> 
> > 1.3 Try to guess what the user want and take action accordingly. Will
> :)))))))))))
> 
> > not work well and might require ESP hardware :). Just kidding what I
> > am talking about are functions that analyses the data stream and take
> > action according to some state space model. One example would be
> > removing clicks in the audio data when -> or <- is pressed. But such
> > algorithms are never completely reliable so it would probably end up
> > removing explosion sounds (or something) as well as clicks :(.
> seeking stuff always call audio_reset. so you can handle ckicks in it.
> not requires any extra stuff, current API is enough for this.
> other things can be controlled using control()
> forget events, this is not an OOP program :)
> 
> > 1.4 Make some external interface running in parallel (like analysing
> > the keyboard pressing using a separate process and give the info to
> > libao2 through some back door). Very ugly.
> forget it.
> 
> > I like 1.2 but it is too generic and I don't feel like implementing it
> > but I don't like 1.1 cause it is a bit to static, and inflexible...
> > Give me input please, anyone with better ideas? Perhaps extend
> > control() to accept generic arguments like ioctl does. Will still
> > require changes in mplayer for new functionality :(
> as everything. mpalyer.c is the boss, it must be modified for new stuff
> related to playback control. pure audio effect options can be implemented
> without any change outside, using subconfig.

I still think control() should be extended at least with one argument
identifying the module one want to send the command to.
I am thinking of something like:
control(unsigned int module_id, unsigned int cmd, void* arg);

> > Ideas for a roadmap:
> > 
> > 1. Refine the libao2 interface to make it easier to implement new
> > features.
> > 
> > 2. Define and implement an extendible buffer management feature with
> > little or no overhead inside libao2 + perhaps a pluggable module
> > interface for new audio modules. I will spy a bit on others first
> > before I suggest a design.
> detail this one
The order in which the modules are called must be configurable (cause
cpuload and some combinations not valid for some input data). I was
hoping to specify this in the config file. The play() function would
then call the function in the specified order (don't worry I will not
try multi threading) using function pointers. All modules operate on
the input or output data buffer so that no mallocing is required.
Nothing fancy, static function ptr list; implemented in asm if too much
over head. 

> > 3. Implement resampling.
> > 
> > 4. Type conversion (change number of bits/sample).
> > 
> > 5. Click removal when fast forward/backward.
> > 
> > 6. Synthetic 4 channel stereo.
> > 
> > 7. AC3 output from any type of input data.
> How?
The spec for AC3 can be found on the net. I would simply synthesise an
AC3 stream using the audio data and send it out through digital output
on the sound card. Do you think there will be some problems related to
this?

> > 8. Functionality for manipulating AC3 and DTS streams (volume and
> > add/remove copy protection, etc).
> > 
> > 9. Stereo perspective panning and calibration for 3 or more speakers. *
> > 
> > 10. Equaliser (boring to implement perhaps steal one and adapt it). *
> :)
> 
> > 11. Reverb and other delay effects (makes the room sound larger). *
> > 
> > 12. Add / remove water marking of the audio streams.
> ???
I hate water marking, I probably won't have time to write it but if I
find a solution on the net I might add it. When it comes to adding
well I guess some people would enjoy writing some interesting messages
to RIAA in place of the water marks :)

> > Feel free to shuffle and come up with your own ideas.
> 
> what about xmms effect plugin support?
Yes good idea I will look at it perhaps chuck it in as number 7 or 9.

> 
> > The options marked with * require advanced user interface features
> > that will be hard to implement using only control(). 
> they need gui?
The Stereo perspective thing could be made using an external cmdline
program that would output what to write in the config file. The EQ
needs GUI ala xmms, perhaps solve this when making module for xmms
plugins. The reverb thing needs either GUI or remote/keyboard input
(few parameters 3 or 4 I think).

//Anders