Subject: Graph reordering (Was: Re: [linux-audio-dev] [OT] marketing hype)
From: Alfons Adriaensen (fons.adriaensen_AT_alcatel.be)
Date: Fri Jun 11 2004 - 16:39:52 EEST
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
This archive was generated by hypermail 2b28 : Fri Jun 11 2004 - 16:35:19 EEST