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

On Tue, Jan 22, 2008 at 06:23:32PM +0000, Bob Ham wrote:

> More generally, LASH isn't a frontend for JACK. LASH (when controlling
> JACK clients) relies on services that JACK provides. This isn't a bad
> thing. The focus shouldn't be on taking control of jackd through LASH
> but in making jackd more server-like, such that you don't need another
> server just to control it.

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.

- 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.

- 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).

- 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.
  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.

- 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.

-- 
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev