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

[Juuso Alasuutari]

On Wednesday 23 January 2008 17:58:05 Fons Adriaensen wrote:
> Having plans for some audio session managament system I've been
> lurking on this thread.
>
> - LASH, or whatever session manager, will have to give
>   special status to JACK, it can't be just another client.
>   In my case, it shouldn't even try to run, stop or configure
>   JACK as some of the things JACK will be used for will be
>   and should remain outside the control of the session manager.

Well, JACK never was a LASH client, and it's always had special status in LASH 
(lashd has a dedicated JACK manager thread). How LASH currently works is that 
lashd is actually a JACK client, which I don't think is an optimal solution 
(at least on a conceptual level).

In my opinion, the concept of "audio session" should _optionally_ include JACK 
server settings. The user should be able to save and load his/her preferred 
JACK settings along with a session (which would sometimes mean that the 
session handler app would kickstart jackd with the new settings). And equally 
important would be that the user could explicitly forbid the session manager 
from altering any JACK settings.

> - The most practical setup I can imagine (for my use, YMMV)
>   is something that integrates the functionalities of e.g.
>   patchage and a session manager.

I agree, and I am hoping that in the future Patchage and/or QJackCtl would be 
able to act as such a control application. But this doesn't mean that the 
control app should have to be a frontend to some all-in-one super daemon 
(like Bob Ham seems to interpret the discussion -- please correct me if I'm 
wrong though).

In my opinion, the control application should control both JACK and LASH 
through abstracted D-Bus interfaces. It should neither be a JACK client like 
QJackCtl nor a LASH client like lash_panel.

> - It would have to support saving/loading a complete setup
>   much in the same way as you would load/save a patch in
>   a soft synth, but without ever touching those things that
>   it didn't start itself (unless told to).

Agreed. I believe this is the purpose of LASH in the first place.

> - Managing JACK connections can be hard, partly because most
>   clients behave in a way that isn't really supportive.
>   Autoconnection can easily lead to circular dependencies,
>   it blindly assumes that you 'own' the connection and should
>   be allowed to control it while the other side doesn't, and
>   for these reasons alone it's a bad idea.
>   Even worse, those clients that do autoconnect from the their
>   own session data will fail if the 'other side' is not yet
>   running (or has not yet created its ports) and they will
>   typically not try again later. So you end up with a result
>   that is generally unpredictable unless carefully controlled
>   in terms of order of starting, and even timing.

This is something I've been thinking also, I'm glad I'm not the only one. IMHO 
the LASH API should be extended to make it mandatory for clients to report 
when they have completed the requested operation. This would apply for 
start-up and settings load/save, so that the LASH server would know when it's 
safe to connect the clients' ports, etc.

Also, the session data should include the starting order of clients, as well 
as a way to control "dependencies". Like so:

  <start id="sampler">/usr/bin/sampler</start>
  <start id="synth">/usr/bin/synth</start>
  <start wait_for="sampler,synth" id="sequencer">/usr/bin/sequencer</start>
  <start wait_for_all="yes" id="daw">/usr/bin/daw</start>

This would result in the sampler and the synth being started simultaneously, 
the sequencer after those two have loaded, and then finally the DAW.

>   Ideally all clients should support a mode in which they
>   will not try to make any external connections, and only
>   rely on the session manager or user to do this. It will
>   be a long time before this is generally supported. I'd
>   like to see some way to prevent clients to autoconnect,
>   if necessary by JACK only accepting external connection
>   requests from a single configurable source.

I also think that when in "LASH mode", clients should refrain from making 
external connections. But instead of adding new features to JACK I think the 
clients should simply behave. LASH as a whole is very dependent on clients 
doing what they're expected to; if we start monitoring and enforcing correct 
client behavior then there will be no end to that.

> - Ideally such a system should be able to distribute clients
>   it starts over different workspaces. The same ones they
>   were on when the configuration was saved. Probably hard.

This is kind of what Nedko suggested about saving some X11 settings, no? This 
is indeed probably beyond the scope of any current plans.

Juuso