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

Fons Adriaensen <fons@email-addr-hidden> writes:

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

I do agree that JACK should have special status to JACK. And we can
probably avoid starting/stopping/reconfiguring JACK, but I think we will
make things easier for public if it does.

Btw, Fons, have you tried jackdbus patches / pyjackctl suite? If so,
what you think about the initiative?

http://sharesource.org/project/jack
http://marcochapeau.org/node/4
http://nedko.arnaudov.name/wiki/moin.cgi/JackDesktopInitiative

> - 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 that this will be the most practical setup for most users. And
thus is very important to be taken into account. OTOH, I'm not generally
against separate server (control) and client (normal app) interfaces. As
far as both can be used in a single app. Dave, can you share your thougs
on this please?

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

I do agree.

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

Kasper Sandberg made a patch (jack_port_connection_acl-v9.diff) that
does add acl to manage who can do connections. I'd like to put it as
part of jackpatches, converted to use the real configuration file. And
of course I hope both jackdbus and connect acl functionality will get
into jack trunk at some point.

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

Can you please explain what you mean by workspaces? The ones a modern
X11 Window Manager typically provides?

-- 
Nedko Arnaudov <GnuPG KeyID: DE1716B0>

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