Subject: Fwd: Re: [linux-audio-dev] MAIA status
From: David Olofson (david_AT_gardena.net)
Date: Wed Jan 17 2001 - 06:30:52 EET
On Monday 15 January 2001 01:22, Guillaume Badaut wrote:
> David Olofson a écrit :
> > As to design, I *think* I have varispeed streaming ports
> > (streaming host interface/protocol included) figured out, but the
> > best way to find out is probably to implement it.
>
> Hello David !
>
> I have some difficulties to understand your description of the
> varispeed streaming ports.
I don't blame you - it's a beast that's inherently quite messy,
especially when you have to interface with it asynhronously from
within a round-robin, callback driven "task". :-)
> No doubt that I lack a more general
> understanding of the MAIA basics (architechtural overview).
Plugins are executed as callbacks, generally called once per cycle in
order processing one buffer. (Just like LADSPA or VST 1.0, that is.)
Plugins can send and receive timestamped events via event queues.
(Similar to similarly to the VST 2.0 event interface for synth
plugins.)
As opposed to most other plugin APIs, MAIA uses the event system for
the major part of plugin<->host communication, and all
plugin<->plugin communication. There are basically no function calls
- except for the process() (LADSPA: run()) call - in either
direction.
> In
> spite of this, could you tell me why you call "Stream Points" what
> seems *to me* be more like "Stream Windows" ?
Yes indeed; I've considered using a more descriptive name. Thanks for
the excellent suggestion! :-)
> Another question : you certainly know that there already exist some
> other media frameworks under development (aRts, GStreamer...).
Yep, and I'm trying to keep up with the developments, looking for new
interesting ideas, and for concepts that I might not have considered.
Unfortunately (or fortunately, depending on how "Not Created
Here"-minded one is ;-), I've not had too many surprizes so far.
Seems like I've thought about pretty much everything - and the
inherent flexibility of the design seems to deal with the rest.
> In a
> few words, could you explain to me how MAIA does compare with these
> tools. In fact, do they have the same goal.
aRts has implementation issues with portability (WRT embeded
platforms and RTOSes in particular) and hard real time processing,
and from what I remember of my discussions with the author, there's
no real, timestamped (sample accurate) event system of the kind VST
2.x and MAIA have.
(Note: A plugin API that's not designed from the ground up to be
driven by timestamped events will most likely hit performance of
plugins that need it - which means practically all professionally
usable audio plugins.)
Some of this can and will be fixed, it seems, but the aRts team seems
to be more interested in network transparency and the like, and less
interested in creating a professionally usable alternative to VST and
ReWire.
I've not studied GStreamer thorougly yet, but I've browsed their web
site and looked at some code. On the plugin and inner DSP loop level,
it basically has the same problems as VST 1.0 and LADSPA; it can't
efficiently deal with sample accurate events, and from what I've
seen, it doesn't even have the concept of sub-buffer resolution.
While I'm at it; VST 2.0 *does* have sample accurate events. However,
these are basically implemented as an optional add-on to the VST 1.0
API, and they're delivered via a separate plugin method call, rather
than to the process() method. Further, the VST 2.0 event interface is
not used as a replacement for the method call parameter interface,
which means that the host *still* has to do the very expensive and
messy buffer spliting hack for sample accurate automation.
MAIA does not need or use buffer splitting at all, except to deal
with feedback loops. (Which actually just means running subnets with
smaller buffers, rather than buffer splitting - there are no extra
function calls or special cases involved.)
> If yes, why
> implementing another media framework instead of improving the
> existing ones ?
Well, for a quick lesson in the issues with upgrading an existing
API, compare VST 1.0 and VST 2.0. The 2.0 event system, and it's use
together with the theoretically obsoleted parameter interface from
1.0 is a particularly interesting area.
> Does MAIA have some particular properties that make
> it much more powerfull (at least in theory) ?
It's designed around an optimized timestamped event system, which
means that sample accurate processing can be done without additional
overhead. The event system only costs CPU time when there actually
are events to process, and a batch of events can be sent or received
without function calls, context switches or similar overhead - only
lean and mean inline code.
> Some time ago, I read the MuCos 0.0.6 code I liked it for it's
> optimized code (in spite of it's simpleness).
You actually made some sense out of it!? Cool. :-)
Anyway, that's exactly the idea; I'm trying to create a very thin and
efficient, but still very flexible and extensible foundation, and
then add various compulsory and optional extensions. You could
compare it to designing some hardware and then writing an OS for it -
or writing an OS and then writing some API libraries on top of that.
The philosophy behind the design is to consider all factors and
applications that result in various demands on the underlying
infrastructure, and then design the infrastructure to deal with that,
using as few basic subsystems as possible.
The event system is not the perfect solution for all kinds of
interaction between host and plugin, and not even between plugins. It
does add some overhead to operations that are normally carried out
between the buffers, once per engine cycle, and it requires some
logic to merge event streams correctly. However, considering that
most high quality audio plugins won't have much use for the unit "one
buffer" or "one engine cycle" in the heavy part; the processing, why
base the entire API on the idea that they will!? VST, LADSPA and most
other plugin APIs have done just that, and we have seen over and over
again that it's just plain wrong, and only complicates trivial things
in real world applications. I'd rather spend some more time thinking,
than repeating the same mistake again.
> So I'm impatient to
> see the 0.0.7 version (named Bond ? ;-).
Not named Bond, but I have to admit that I've considered it! :-)
The next release will actually load a plugin and communicate with it
- possibly even do some real signal processing. (I have some fun code
lying around that I could wrap up as plugins rather easily, so I
might just as well do that while I'm at it.)
I'll try to include a MIDI driver plugin as well as a sequencer with
a demo track for the ones without a MIDI controller. (That's a "bug"
in the softsynth hack - you can't get a sound out of it without some
MIDI input! :-)
Not too far into the future, I might even hack some SDL based video
plugins, to get started with the non-audio side of the extensions and
data types. I'm also thinking about some sort of protocol or data
format for generating, processing and rendering 3D scenes. Logical
plugins would be various 3D visualization plugins that just pipe
commands into an OpenGL rendering plugin, and video->vector
converters to do high quality real time magnifying and special
effects on video streams. Remains to see how crazy I can get!
//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 -'
This archive was generated by hypermail 2b28 : Wed Jan 17 2001 - 07:00:07 EET