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
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Fri Jan 25 20:15:09 2008
This archive was generated by hypermail 2.1.8 : Fri Jan 25 2008 - 20:15:10 EET