>>> * 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
