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