Subject: Re: LADPA (was Re: [linux-audio-dev] emagic (logic) drops VST support under OS X)
From: Paul Davis (pbd_AT_op.net)
Date: Wed Sep 04 2002 - 22:57:19 EEST
>>> * lock-free, cross-process, cross-client event/object communication.
>>> this is a tough one especially if events/objects can be of arbitrary
>>> size. maybe a proof-of-concept implementation could use fifos/
>>> AF_UNIX sockets here initially. eventually i think one will need to
>>> use shm like audio signal transport already does.
>>
>>Like Paul said, it needs someone to implement a malloc-alike for jack.
>>Tricky, but not impossible.
>
>a possible halfway solution:
>
>* client (or jackd when initializing) registers a new sized & named
> object type.
>
>* libjackd allocates a shm segment containing an array of n instances
> of the data type, where n is a hard limit from then on.
>
>* whenever such an object is to be emitted, jackd fetches it from the
> 'cache' shm segment. the object is referenced by type and index into
> the type cache, so it is usable cross-process, and because it's
> cached it is realtime capable for free.
>
>* the client/plugin that eventually 'consumes' the object returns it
> to the cache.
>
>that doesn't solve the generic malloc problem (strings of arbitrary
>size) but it does look attractive for the common case of fixed-size
>events.
yes, and it would be less than a few hours to get it working.
the problem is that many of the interesting data types are variable
sized. MIDI is the most obvious.
>>I'm not 100% sure that using the jack audio data graph for this is optimal
>>(it will complicate the graph and maybe make it difficult to pick a good
>>low-latency ordering), but I also haven't thought about it hard enough.
>
>not sure either. two or more graphs will make it more complicated for
>the user en tout cas.
i think the right thing to do is to add information on whether ports
of a given type should participate in graph ordering. the default
would be just to use audio ports (perhaps). maintaining N graphs seems
like a very bad idea. the only goal of the graph is to establish a
call order; if connections between ports of type "foo" make no
difference to this, they can be safely ignored; if they can't be
ignored, then by extension they have to used in computing the graph.
--p
This archive was generated by hypermail 2b28 : Wed Sep 04 2002 - 23:06:55 EEST