Subject: Re: [linux-audio-dev] No IPC in LADSPA?!
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Tue Mar 28 2000 - 06:32:49 EEST
>Catching up on this weekend's LAD postings, I just became aware that
>LADSPA will not support IPC. I personally dislike plugins and prefer
>standalone apps communicating over IPC whereever possible, since it
>means more freedom for the end-user to mix and match what he
>personally considers to be the best at each task.
Hmm. Not a Cubase or Logic user, eh ? Those guys seem pretty happy to
"mix and match" at the plugin level, rather than the application one.
>That leaves MuCoS which, as it has been mentioned, __does__ support
>IPC. However, MuCoS is inherently a batch system, not streaming.
Not true. MuCoS has no particular orientation towards batch or real
time.
>By this, I mean that it takes queues of timestamped events and
>processes them in chunks, rather than delivering non-timestamped
>events individually, as fast as it can.
Quite the opposite in fact, though your description is superficially
correct. The problem with "delivering individual events as fast as it
can" is demonstrated rather nicely in Quasimodo. Because of the way it
implements "patches" between modules, external events (GUI stuff, MIDI
data, etc.) that alter parameter values happen *too* fast. How can
they be too fast ? They are not synchronized with audio generation,
and so a parameter can change in the middle of the generation of a
chunk of data from one module, even the change is intended to affect
(perhaps) modules before the one that was just affected. the result
is that is becomes impossible to do sample accurate processing, unless
you use a block size of 1.
Instead, you have to work with the knowledge that the data being
generated at time N will actually be heard at time N+n, where n is
related to the buffering/latency of the output system. Then you
collect all the *timestamped* events that occur while the chunk of
data that will start to be heard at N+n is being generated, and pass
them in for the next chunk. The result is that the events have their
effects at the *right* time, and you can do sample accurate
processing with all the computational benefits of block sizes > 1.
>What is the correct solution for folks like me who want to stream
>non-timestamped events between different processes ASAP (not
>guaranteed hard realtime, but as fast as possible)?
For point-to-point communication, if the data flow rate is not an
issue (ie. its not audio or video), than a Unix pipe will probably
work just fine. If you need to multiplex, then use shared memory
queues. In short, use the existing IPC mechanisms, since what you want
is in fact *IPC* not a plugin API.
--p
This archive was generated by hypermail 2b28 : Tue Mar 28 2000 - 06:55:49 EEST