Re: [LAD] Summercode 2008: LASH as a D-Bus service

On Fri, 2008-01-25 at 12:51 -0500, Paul Davis wrote:
> 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.

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.

> 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@email-addr-hidden>

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev