Subject: Re: [linux-audio-dev] Ideas for AES/LAAGA/whatever (was Re: sound API libraries, servers, etc.)
From: Paul Davis (pbd_AT_Op.Net)
Date: Thu Apr 26 2001 - 04:37:51 EEST
>Now then, as an exercise, try thinking in this space instead of the
>standard UNIX space (i.e. of processes with rigid boundaries, and a
>preference for monolithic executables and shared libraries -
>monolithic on Elate's scale, at least).
it may interest you to know that i've had experience with much more
experimental OS designs than that. none of that changes my conviction
about the distinction between DSP plugins and "entire applications".
>Now, based on something like Elate, what difference is there between
>connecting big applications together and connecting small plugins
>together ? In the main processing loop that you describe, the
>`server' is still calling the shots, asking each plugin to process X
>samples of data. I can't see the difference at this level.
The difference is that in LADSPA, the plugin is deliberately intended
to know nothing about its output destinations. It has audio (and
possibly control) output ports that are just pointers to memory, and
it writes there. The plugin does not control the connections of the
ports; this is done by the host (presumably at the request of the user).
Thats phenomenally inefficient when dealing with entire applications
that are processing large-ish quantities of data all the time. It also
requires too much intelligence in the host when the plugin is a large
scale application (e.g. ardour). The AES system that Kai took as a
starting point provides
write_to_channel();
read_from_channel();
these allow the plugin at the AES level to dictate where its output
goes and input comes from, and, as an implementation detail, to do so
with zero buffering between it and the DMA buffer of the audio
interface.
to be more specific, ardour, for example, doesn't even have a fixed
number of audio output ports (if one were to use that analogy). it has
a potentially unlimited number of internal objects, each of which
might output 1,2,3,4...N signals to the same channel, or to a set of
different ones, or somewhere in between. the number of objects changes
dynamically, as the set of audio output ports changes even more
dynamically.
thats why i came up with the idea of the server providing functions
that copy data to a given channel rather than the
LADSPA/VST/DirectX/etc. model in which the plugin has no clue where
its output is going. in the AES model, a plugin merely has to notify
the server that it intends to possibly use a given channel, and then
it can use the channels directly. this is much more efficient in terms
of data copying and optimization than an "ignorant" model like VST or
LADSPA. However, I continue to think that the "ignorant" approach is
correct for DSP plugins.
>sample processing. The main loop is very similar if not identical to
>a LADSPA main loop.
Its similar in the sense that it looks like:
foreach plugin { plugin->process (nframes); }
but its unlike it in many other important senses that follow from what
I wrote above.
>We could (in theory) implement something like what you describe by
>taking LADSPA, and then making a specification for a special kind of
>LADSPA server that accepts commands from applications wishing to be
>connected up in a particular way.
No, you couldn't. LADSPA doesn't contain the idea of a plugin
reassigning its own outputs, or even requesting that they be reassigned.
>Not that I'm necessarily suggesting this is the way to go - just to
>point out the possibilities as an aid to thinking around the issue.
In a few weeks, I'm giving a talk in Italy called "2 Years Reinventing
The Wheel: Linux as a platform for pro-audio". When I started on this
adventure a little over 2-3 years ago, I was very dismissive of the
solutions that Steinberg, Digidesign, Cakewalk and Emagic had come up
with, viewing them primarily as a function of the terrible OS
platforms they had chosen to use. I don't have this point of view
anymore. I have a great deal of respect for Steinberg in particular
who I think have taken a very pragmatic approach to solving the
problems of computer-based audio systems.
Why do I raise this? Because VST2 is probably the most developed and
sophisticated audio plugin standard around (much more so than LADSPA),
and even Steinberg have developed ReWire as an entirely separate level
of inter-connectivity. I am more than willing to trust their judgment
that this can't be done well with a system that looks like VST. Since
LADSPA is essentially a reimplementation of the main design features
of VST1, I believe that something quite different from LADSPA is needed.
>This means that the `server' now has several possible roles:
>
>- It runs the main loop for the plugins
>
>- It accepts requests from applications to get themselves connected or
> disconnected to/from the various busses (as you describe).
yes, but stop here. everything you describe subsequently is beyond the
scope of what Kai was proposing. there has been no suggestion of
providing anything but audio connectivity.
there are lots of excellent reasons that have come from the
discussions we've had here over the last year about a GUI standard for
LADSPA that make it clear why the AudioEngine Server (using my
nomenclature) should not be involved in handling control data. i think
that the same applies to "commands".
the proposal, as i understood it, is to connect up the *audio* data
flow between applications so that they can share an interface and
their own data. nothing more than that.
david olofson's somewhat mythical MAIA is perhaps a candidate for what
you're describing; though i trust david's design sensibility, MAIA has
yet to emerge as anything except a consumer of large amounts of LAD
bandwidth (mea culpa :)
--p
This archive was generated by hypermail 2b28 : Thu Apr 26 2001 - 05:11:10 EEST