[MPlayer-dev-eng] Audio filters first design proposal

[joy]

On Tue, Jul 09, 2002 at 08:01:18PM +0200, Arpi wrote:
> Hi,
> 
> > I have written a design proposal for the new audio filter structure,
> > it is attached to this mail. Have a look, at it. I have so far not
> > addressed the problem of memory buffers. I would still like to make
> > them dynamic all the way into the buffering that is made by mplayer. I
> > need to start looking at where I should put the calls to init, uninit,
> > play, etc - please advise me on this.
> 
hi, i also wanted to take a look at yout proposal but didn't got the
time for it till now. it's maybe off topic right now but still
interesting for me. i think also in the sense of in which direction
should the whole audio layer go, what is needed what could be improved
or avoided.
i think also the handling and placing of a (pre)-audio-buffer is one
of the keys in this discussion. one first thing which i stated for me as
true, and it takes a long time to recognize that ;), is that mplayer
is a multimedia-application mainly based on video processing. it needs
also audio but it will and never could be an only audio-app cause it
has to process video. its maybe simple but has some serious
considerations. so one of it is that audio-buffer(s) have always to be
large enough to have enough frames to play even while reading from
slow media for example old cdrom-drives or damaged media. but
increasing buffer means always increasing latency and this makes 
'realtime'-processing which is needed for most audio-(art)-work
impossible. maybe some posibility to set it dynamically would be fine.
the other is the float/int problem which makes audio-processing not
easyer.
but back to the latency issue, mplayer still has elements which would
make it possible to be a realtime app or connect it to
realtime-apps. rtc could be used as timebase, it has optimized and
fast decoders, and by improving the enviroment (see for example 
http://www.cse.ogi.edu/~luca/firm.html) latency could be dramatically reduced.
i vote also for the poll-mechanism (ao_* determines how many samples
it needs) that arpi described cause this is the only way to connect
mplayer to other audio-apps in 'real'-time.
at least i would say (sorry to the developers) that a plugin layer
between decoder/encoder <-> ao_* is a waste of bandwidth cause there
are many posibilities to aply effetcs more 'effective'. so you can put
the wide range of LDASP-plugins near at hardware-layer in alsa-library
(at runtime) or with an upcoming ao_jack it would be possible to do
any audio-processing after mplayer and even connect it back or whatever.
but its also ok to have a set of usefull ready-to-use plugins for
users who don't want to mess around with audio things.

-- 
regards

____-
joy

________/\---------%%%___________-----------
webcast every sunday 2000 cest at pingfm.org

pgp key at: x-hkp://wwwkeys.de.pgp.net