On Fri, Jun 11, 2004 at 08:37:09AM -0400, Paul Davis wrote: > you cannot modify the graph in JACK while the graph is being used to > process audio. you do not know how long the graph modification will > take if you try to do it (for example) right after you're done with > one process cycle. the only sure way to do this is to use lock free > parallel programming techniques. this is still a highly experimental > area of computer science, and i have yet to see more than a glimmer of > a technique that would actually work in a complex real time system > like JACK. the designs that exist to date tend to work better (if at > all) in situations where the software objects do not have much > "weight" to them. the JACK graph describes quite a resource-heavy > state (shared memory, device driver handles, processes, etc. etc.), > and making a copy of it so that you modify it and then switch pointers > is not a practical approach.
It can be done, but as you say it's not simple and requires very careful design. The 'heavy state' is AFAICS not the real problem. Heavy things can be put in place before the actual graph reordering is done or removed after. This does not need to be done in the RT thread. There seems to be a deeper problem: the existence of non-RT callbacks together with the fact that jackd knowns only about one thread in the client. This means that jackd has to wake up the client's RT audio thread in order to do a callback. While the callback runs, the audio thread is not available to do the normal process callback, since it's not waiting for the trigger. One solution would be to require that the RT thread immediately hand over the callback to a lower priority thread, but this means we have no real callbacks, but notification events. > the fact that some systems can do live repatching without xruns is > either good luck, or a function of them using very lightweight objects > that don't directly reference expensive resources. Not entirely true. If the connect/disconnect calls are allowed to be blocking (which of course means they can't be used from the RT thread), OR if they are allowed to be asynchronous (which means they just pass on a request that will be acted upon some time after they return) then it is perfectly possible even if some heavy objects need to be handled. I wrote a JACK-like system doing exactly that about six years ago. 'No hickups' during connections was a requirement, and I had to prove compliance. -- FA
