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

[Bob Ham]

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 at bash.sh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20080125/d481772a/attachment.pgp>