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

> 
> 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. 
> 
> Ciao,
> 
> -- 
> FA

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.

But I think we should clearly separate which could be a "fresh look"..., to the current situation Paul wants to address, only that we are still all waiting.... of the "how" ((-;

Stéphane 

1323418452.5730_0.ltw:2,a <D7EB817E-625A-403F-B14F-6A782ECC6330 at grame dot fr>