11 Jun
2004
11 Jun
'04
11:49 a.m.
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