Re: [Jack-Devel] The Situation(s) With JACK

Le 9 déc. 2011 à 10:18, Fons Adriaensen a écrit :

> On Fri, Dec 09, 2011 at 09:14:13AM +0100, Stéphane Letz wrote:
>>> 
>>> One good reason to have a fresh look at what Jack is
>>> supposed to do is the fact that SMP systems are more
>>> or less the norm today. And complex apps (A3 being
>>> the prime example) are taking advantage of that and
>>> organising their internal processing using multiple
>>> threads. No doubt more will follow. Yet, scheduling
>>> in Jack remains on a per-process basis. That means
>>> that e.g. if app B depends on input from app A, the
>>> entire B is made to wait until all of A has done its
>>> work, while the actual dependencies may be much more
>>> fine-grained. There are several ways to address this.
>>> One would be to have a single 'audio engine' process
>>> and delegate all audio processing to it. That would
>>> of course mean that all security is lost, a single
>>> rogue audio routine could bring down everything. 
>>> Another solution would be to make Jack trigger port
>>> or groups of ports instead of a process. So anything
>>> in B that depends on A would run as soon as all output
>>> from A that a part of B depends on is available. In
>>> other words, the signal graphs becomes global. That
>>> would also allow B to be a insert of A without adding
>>> latency etc.
>>> 
>>> But I'm dreaming. 
> 
>> I second those concerns about better SMP system support,
>> but note that multiple JACK clients per process (which
>> is perfectly possible with jack2) already allows to do
>> (or at least to "test" even if the model is not perfect)
>> what you are speaking about.
> 
> Yes, but only if the dependencies are more or less static,
> which is usually not the case. If they are not, you would
> not only need to migrate modules from one client to another 
> (possible), but also ports (hairy).
> 
> They way apps like A3 schedule their internal multithreaded
> computation is entirely dynamic. A module is added to a
> queue when all its inputs are available; sooner or later
> one of the computation threads will take it there, execute
> it and provide triggers for the next ones. There is no
> static schedule, simply because without knowing the exact
> execution time of each module you can't compute one.
> 
> If you want to seamlessly integrate such networks then
> the same thing should happen between processes. So, when
> a Jack client has computed the signal on a particular
> output port it should set that port to 'ready', Jack
> transfers this status to all ports this one is connected
> to, and the owners of those destinations decide what to
> do. In theory. In practice part of that dynamic logic
> will have to be pushed into Jack somehow to avoid useless
> process switches. How to do that is the main challenge.

Discussion to be followed later on...

> 
> On a related topic: it seems that OSX now has a system
> that allows a userland process to schedule a task to be
> executed at a defined priority by a global 'engine', and
> in a way that is much more efficient than creating a thread
> for it. The way I understand it (which may be wrong) is that
> it uses a pool of system threads instead. Do you know more
> about this ? 

I guess you speak about Grand Central Dispatch (http://en.wikipedia.org/wiki/Grand_Central_Dispatch). The project has even a "open source" side called libdispatch (http://libdispatch.macosforge.org/).

I did some tests with it and the result is: it is interesting, a bit Apple centric for now with this new "Block" concept, linked with the LLVM project (which by itself is really really interesting, but also a bit Apple centric..)..., but "obviously" (I mean "as usual") not designed for real-time context, and "as usual" almost nobody ready and available to push anything in this direction.

Stéphane 

1323423388.15060_0.ltw:2,a <9DCAA38B-A156-4E68-A819-6A5946D0402C at grame dot fr>