Subject: Re: [linux-audio-dev] No IPC in LADSPA?!
From: David Olofson (david_AT_gardena.net)
Date: Thu Mar 30 2000 - 08:46:51 EEST
On Mon, 27 Mar 2000, David Slomin wrote:
> Whoa!
>
> 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. Keep in mind that
> my primary interest is in low bandwidth control messages (think MIDI),
> not signals, so standard IPC mechanisms normally __do__ have low
> enough latency for me. Thus LADSPA has lost a lot of interest for me.
>
> That leaves MuCoS which, as it has been mentioned, __does__ support
> IPC. However, MuCoS is inherently a batch system, not streaming.
> 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.
That's the way it's indended to work, and the way it has to work with
callback plugins. It's a bit different with the client/server model,
though.
> 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)?
I have been thinking about this... It's inherently supported by the
MuCoS event system design if used with the client/server model, ie
IPC, as there's not necessarilly a fixed cycle time. Clients may send
events or check/sleep on their ports at any time.
As for timestamps, events with real timestamps that arrive too late
should be handled in a way that minimizes the effect of the missed
deadline. Using "process ASAP" timestamps (ie time = 0) means that
the target client is expected to keep working as long as there are
events in the input queue, and then go to sleep. (Note: A client that
has on audio engine will most likely run it's normal engine cycles
and just grab these events whenever it checks the client/server
ports. This may well be only once per cycle.)
//David
.- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
`------------> http://www.linuxdj.com/mucos -' | Open Source Advocate |
.- A u d i a l i t y ------------------------. | Singer |
| Rock Solid Low Latency Signal Processing | | Songwriter |
`---> http://www.angelfire.com/or/audiality -' `-> david_AT_linuxdj.com -'
This archive was generated by hypermail 2b28 : Thu Mar 30 2000 - 13:26:41 EEST