25 Jan
2008
25 Jan
'08
3:47 p.m.
On Fri, 2008-01-25 at 12:51 -0500, Paul Davis wrote:
On Fri, 2008-01-25 at 17:29 +0000, Bob Ham wrote:
Well, I'm surprised to see jack_set_sample_rate_callback in the docs
then :-) I appreciate your point, though; very few clients implement
that callback.
JACK Rack pays attention to the sample rate when it saves and loads
files; it will recalculate plugin control values if they're sample
rate-dependant and the current rate is different to the rate when the
file was saved. However, it *doesn't* implement a callback to do the
same; that was always on the TODO list.
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.
Indeed. JACK Rack implements file-based sample rate changes because
there is the issue of taking a save file to a different setup. It
doesn't implement a JACK callback because a sample rate callback is such
a rare event as to be a non-issue.*
Regardless, what I'm pointing to really is an ideal. There's a scale of
dynamicity. At one end is a system where each bit of the server is
behind an abstracted interface and implemented through dynamically
loaded and unloaded modules, where these parts communicate through
well-defined tubes, where every change of state has its appropriate
client-side callbacks, every client implements those callbacks, world
peace prevails, etc, etc.
At the other end is a jackd with just one big main() function.
As it is, jackd is somewhere in between. What I'm proposing is a shift
up the scale a little, towards world peace. There will be a limit where
the costs in terms of client-side complexity outweigh the benefits. I
think, though, that quite a lot could be done to improve the situation
before hitting that limit.
Bob
* I seem to recall we've had this exact discussion before :-)
--
Bob Ham <rah(a)bash.sh>