25 Jan
2008
25 Jan
'08
1:51 p.m.
On Fri, 2008-01-25 at 17:29 +0000, Bob Ham wrote:
Having said that, JACK should be very much more dynamic. You should be
able to suspend the engine loop, change any setting, even change the
driver, and resume graph processing without any hiccups. If any
operation breaks real-time safety, clients should be able to register
callbacks to be notified of when real-time operation stops and when it
resumes (assuming all graph-execution is real-time.)
making jackd/jackdmp do this is easy.
the reason JACK doesn't do this (at present) is because of the burden it
represents to clients. one of the main reasons JACK has been widely
adopted is that it is simple and it hides almost of all aspects of the
h/w from clients, including sample rate.
if the model changes to one in which clients have to deal with arbitrary
changes in sample rate, presence of absence of h/w ports and more, its
not that it cannot work, but it presents a more challenging API for many
complex clients.
its has almost no impact on jack itself. so, before pushing for this
kind of thing so enthusiastically, i suggest we first consider how many
clients want to live in a processing graph that is truly this dynamic.
--p