NOTE!
Think twice before doing “reply all” on this,
as I left all the mailing lists in the CC.
Wed, 06 Dec 2000 Pasi K?rkk?inen wrote:
Hello,
As you all know, there are many separate video-player
projects for Linux currently going on.
And nobody wants to cancel his project, because everyone
thinks, his is the only one that’s worth working on
(me too Every player so far has its pros and cons.
Mine for example lacks a GUI, others have nice looking
skin capable GUIs but don’t work at all. So working
together could help us a lot.
That’s why I’m working on the MAIA plugin and integration API, and the reason
why I’m trying to make it usable for more than high end audio processing.
Short story:
1. I was developing an audio sequencer for Windows. Of course, the
useless real time performance of Windows forced me to move on to...
2. RTLinux. Incredible RT performance (few ?s worst case scheduling
latencies), but there were no audio drivers. I started writing
a kernel API compatible Driver Programming Interface to make porting
easier.
3. Starting to design my audio engine for RTLinux, I soon realized that
I'd need a plugin API and lots of plugins. I joined the Linux Audio
Dev mailing list, and all of a sudden, I found myself in the middle
of a wild plugin API design discussion.
4. Meanwhile, a viable alternative to RTLinux (for audio applications)
came along: The Linux/lowlatency patch. This allows SCHED_FIFO
threads to schedule with worst case latencies low enough to process
audio with 2.1 ms latency. (Beats BeOS at it's own game, and that's
without bypassing the standard APIs, or requiring high end hardware.)
5. The plugin API discussion soon resulted in LADSPA. It's a simple,
VST1.0 style audio plugin API, written mainly by Richard M. Furse.
It does a great deal of what the audio hackers need, and it's easy
to use. However, One Size Does Not Fit All, which was clearly
indicated the other week, when the list was again flooded with
plugin API related threads.
6. The MAIA project (formerly called MuCoS) was never put on hold, and
is now close to the alhpa testing stage.
The ongoing discussions and other factors have influenced me during the design
stage, and the result is that MAIA is now designed from the ground up to deal
with everything that LADSPA does, the people have been missing in LADSPA (most
importantly timestamped events), and a few other things, such as allowing
plugins to deal with all kinds of data, rather than just the 32 bit floats
that are hardcoded into LADSPA, VST 1.0, VST 2.0 etc.
As to audio functionality, MAIA aims to provide basically the same
functionality as the VST 2.x plugin API (allows plugins to be loaded as shared
libraries and executed in whatever thread the host decides on; usually a single
dedicated audio thread for all plugins), and the ReWire standard (allows
multiple applications to run their audio processing in the same thread, in
order to achieve sample accurate sync, and the lowest possible system latency).
Both off-line and real time processing will be supported, but the latter is the
main focus, as that’s where you’ll find the most important problems that we need
to address.
[…]
I just registered a project called “Open Media Interface” to the
sourceforge. Let’s see if they’ll accept it.
That project is dedicated to creating a good api/plugin/codec-system for
Linux (and other unices). Something like we have in windows…
By creating such a system, people could continue developing their
own players (or editors or whatever) and have easy access to all supported
fileformats. Both reading and writing to those formats.
That sounds very much like what we’re doing around the audio community.
(Except that we prefer to view it from the real time streaming perspective,
which sometimes results in a different terminology. For example “files” are
painfully slow and unreliable WRT timing, so we use heavily buffered “disk
butler threads” to deal with them. Normal plugins are never allowed access files
directly. Likewise, multithreading scheduling latency is a serious issue for
real time audio, so we have to run all plugins in the same thread, at least on
current operating systems, for acceptable reliability and audio latency.)
What I want to do is to have the different kinds of media handled in a more
"organized" manner than by using entirely different plugin APIs and protocols.
Basically, we’re all dealing with the same semantics. Only frame rates and data
types differ. If the same low level interface is used for all kinds of plugins,
we get advantages like implicit audio/video sync, engines that can easilly
handle both audio and video plugins, common solutions for network streaming,
harddisk recording, automation and so on.
//David
…- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' ..- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |
--------------------------------------> david at linuxdj.com -’> On Tue, 5 Dec 2000, Dirk Farin wrote: