Subject: Re: my take on the "virtual studio" (monolith vs plugins) ... was Re: [linux-audio-dev] ardour, LADSPA, a marriage
From: David Olofson (david_AT_gardena.net)
Date: Sun Nov 19 2000 - 12:24:53 EET
On Fri, 17 Nov 2000, Paul Barton-Davis wrote:
[...]
> >layer really SOLVES the problem with toolkit indepenadance of audio processing
> >plugins. LADSPA is simply not up to the task of doing so, but with a
> >middleware like MCOP it becomes really easy. And you don't care that your GUI
> >is running in one process/thread while your signalprocessing is running in
> >another, because the transport is done automagically and transparent.
>
> These things don't seem connected to me. LADSPA has to do with
> connecting audio flow within a single execution context. MCOP has to
> do with moving data around in a transport-independent way. If you make
> the concession that low-latency audio apps don't want transport
> independence for audio (please, please make that concession :), than
As long as we can keep track of when plugins are going to access what
data, this transparency doesn't really need to be in the API - it's
just a matter of getting the data to the right place in time. For a
low latency audio centrict API, I'd rather keep that out of the API
itself, while providing the information that hosts, communication
infrastructures etc need to implement whatever communication systems
they need.
Just to demonstrate the difference between cycle/buffer based plugin
systems and generic applications (using IPC, RPC, fifos, sockets etc
etc), take a cluster where two threads are running on two nodes,
communicating lots of data.
If the two threads were actually real threads, using normal IPC
methods for communicating, they would rely very heavily on SAN
latency for performance. If they were using shared memory methods,
that would require hardware support for shared memory over the SAN,
such as HiPPI NICs, or at the very least, kernel level emulation of
shared memory interfaces.
Now, if the "threads" were actually plugins (according to the LADSPA,
VST, MAIA/MuCoS,... etc model), we could assume a few things, *even*
if the APIs assume that there is shared memory for the buffers.
First, we can assume that both plugins will run one cycle at a
time, virtually in sync, at the same rate. Further, we can assume
that the plugin execution order defined by the processing net defines
the node dependency structure on our cluster; that is, if plugin A
feeds plugin B, we just have to make sure that the output data from
plugin A is available to plugin B before it executes. No hardware
support needed here - we know that the data is ready for transmission
when the run() call returns to the host.
Why complicate things in order to deal with the special case, when it
can be solved very efficiently anyway?
> LADSPA is fine for that purpose. OK, then we need some other mechanism
> for distributing non-audio data. I don't care much about this, not
> because its not important, but precisely because whatever the method,
> I am pretty sure it will be transport independent. MCOP, libsigc++,
> MAIA (GREAT NAME, David O.!) - its really not that important to
I like the *name* - short, simple, pronouncable etc, but I'm not sure
about the fact that there are countless things and persons with
either that name, or that acronym... OTOH, that's probably to be
expected if you come up with anything that sounds ok. :-)
(And there are few things you can find on the 'net using only one
keyword these days, anyway...)
> me. What I really care about is tightly controlling the audio flow.
Speaking of which; control timing is pretty important as well, which
suggests that signal/RPC style stuff won't cut it - timestamps are
needed as well.
(There *are* situations when you want this kind of stuff transmitted
and taking effect as quickly as possible, but in pro audio, those
situations are *exceptions* - in generaly, you want full control and
accurate, 100% repeatable timing.)
> Note that I *do* understand the broader ramifications of MCOP. I think
> that people wanting do things in the performance world could use it
> with a network of systems for some very interesting effects. Audio
> rendering could use it very effectively too. I just happened to be
> *very* focused on applications that are replacements and extensions of
> things done now by dedicated hardware. In such systems even the
> relatively low overhead of the function generated by the MCOP compiler
> for same-thread execution strikes me (without knowing too much about
> it) as more than I want to deal with.
Besides, I still believe that any API can be made simpler and faster
if it's more specialized. Just moving from general RPC style systems
to a cycle based system should remove a great deal of complexity (see
above), and defining other RT related things more strictly should
enable even more simplicitly and determinism.
> I could be wrong. And I mean that!
Well, there are more and less efficient ways to do things, but my
bet is that you're quite right. Nothing comes entirely for free.
That's why I'm saying that LADSPA should probably remain the API to
use for small/fast plugins that don't require the added features of
MuCoS/MAIA/whatever: all of these features cannot come without any
kind of overhead. (Although I'm hoping that timestamped events are
quite a bit more efficient than buffer splitting + extra function
calls...)
//David
.- M u C o S -------------------------. .- David Olofson --------.
| A Free/Open Source | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
| for | | Open Source Advocate |
| Professional and Consumer | | Singer |
| Multimedia | | Songwriter |
`-----> http://www.linuxdj.com/mucos -' `---> david_AT_linuxdj.com -'
This archive was generated by hypermail 2b28 : Sun Nov 19 2000 - 16:01:35 EET