Le 17 f�vr. 05, � 15:43, Paul Davis a �crit :
you can have absolute minimal latency, but that requires locking the graph against use when it is reordered.
AFAICS, that is not the real reason. If it were, the simple solution would be to let the engine continue using a copy of the current graph while the new one is being computed and the required resources created.
Probably if look you into it deep enough you'll find that the necessity to stop processing while new clients are created or when the port connection change can be traced back to the combined effect of:
1. only having one JACK-controlled thread in each client, 2. the synchronous nature of the API calls that modify the graph.
stephane's new OSX implementation (jackdmp) avoids both of these, and ends up with an extra process-cycle worth of latency. he does exactly what you suggest above. is it avoidable? i don't know. stephane didn't seem to think so when we talked about it briefly on IRC. maybe it can be.
--p
Just one word about the "one extra process-cycle worth of latency": this is not exactly related to the fact that the graph is updated without stopping the audio thread : one could perfectly keep the current model (where the server waits for the client graph execution end to write the output buffer ) *and* have the "don't stop audio thread" property most of the time.
The "one extra process-cycle worth of latency" is a consequence of another idea to implement a more "robust" system, where robust mean a system where *some* audio clients may fail during one cycle without stopping the entire graph.
Stephane
