[LAD] adding session notifications to jack

[torbenh]

On Sat, Nov 21, 2009 at 04:37:17PM -0500, David Robillard wrote:
> On Sat, 2009-11-21 at 18:49 +0100, torbenh wrote:
> > hi...
> > 
> > on a side note to the LADI discussion, which might even be my fault,
> > i want to tell you what i am currently up to.
> > 
> > in my opinion the inherent fail of session handler stuff, is that
> > somehow it wasnt easy enough or too complex to integrate lash support
> > into apps.
> > 
> > also many people didnt like to use some other ipc mechanism...
> > 
> > so to me the most natural way to do session notification was adding it
> > to jack. most apps are already listening for some jack callbacks.
> > (at least they should be listening for shutdown :)
> > 
> > so in my working copy of jack1 i have added 2 API calls:
> > 
> > 
> > typedef char *(*JackSessionCallback)(jack_session_event_t code, const char* session_dir, const char* prefix, void *arg);
> > 
> > int jack_set_session_callback(jack_client_t *client,
> > 			    JackSessionCallback session_save_callback,
> > 			    void *arg);
> > 
> > struct session_command * jack_session_notify (jack_client_t* client, jack_session_event_t code, const char *path );
> 
> What is jack_session_event_t?

enum { JackSessionSave, JackSessionQuit }

> > by calling jack_session_notify() the session callbacks of the listening
> > clients are invoked.
> > they are supposed to save their state, and return a string which
> > specifies, how they want to be restarted. the prefix parameter is unique
> > and there is a method to make this persistent over session reload.
> > 
> > the aggregation of the returned strings and unique ids is returned by
> > the notify call.
> 
> What is this unique ID?  Unique ID of what?

unique id, which is meant to persistent. a unique client id for the
session. 
jack_client_open is extended to accept this uuid. so upon session
restore, the client will have the same uuid again.
and the session manager will be able to query its jack client name.
and then be able connect things again.

> > so... a potential session handler is still required. and it needs to be
> > able to query the portconnections. 
> > in order to restore them. 
> 
> This could simply be implemented as another jack client, though, right?

yes. the session handler is simply another jack client.
(it might even be ardour :)

> 
> > but clients are not required to have an extra dependency in order to
> > support sessions. 
> > 
> > you may have noticed that this is currently ignoring alsa connections.
> > but i think we only need to add a way to publish an alsa seq id
> > via this protocol. 
> 
> Personally I think it's pretty reasonable to expect Jack session
> management to only support Jack things.  Jack is portable to systems
> where Alsa doesn't exist, for one thing.  We have MIDI and bridges
> between them, just keep the system clean, I say.  The session manager
> can deal with that crap if it wants to.

i have added:

void jack_client_set_cookie( jack_client_t *client, const char *key, const char *value );
char *jack_get_cookie_by_uuid( jack_client_t *client, const char *uuid, const char *key )

now. this allows for publishing such things.

> 
> > the only disadvantage i am seeing currently is that apps are treating
> > jack like an abstract audio output, and getting a jack signal up to the
> > gui layers where the invokation of save is generally happening is a bit
> > cumbersome. 
> 
> I like the simplicity of this, but this last part is a problem.  I'm not
> sure doing this in Jack1 where all callbacks are in the process thread
> is really appropriate.  Then again, I don't think all callbacks being in
> the process thread is appropriate, period ;)  I guess this is just
> another case of this error anyway, but an extremely bad one.  You're
> going to get a pretty severe drop-out saving a ton of stuff to disk in
> the audio thread!!

yup. i will fix this up. its not really complicated to do.
however it hasnt been a real problem yet. 


> 
> But this leads me to the main point I want to make:
> 
> My take on this general thing is that a simple API like this is very
> definitely the right path, but if anything I would like it not even tied
> to Jack itself either.  The reason session management has failed to take
> hold is too much implementation-defined crap, breaking APIs, complexity
> to implement, and all that kind of thing.
> 
> How about taking it one step farther:  define this API in a single C
> header, which would be very small, not tied to ANY implementation
> whatsoever, and implementable by both plugins and hosts (this last part
> is a very big win IMHO).  All this header would define is a descriptor
> (struct) with the necessary methods.  Sort of a ladspa.h for session
> management, except even simpler.  How you actually get this descriptor
> would be the only implementation dependent part (e.g. a host could pass
> it to a plugin, or Jack could have a single new call to return it).

interesting idea. i am not sure about the semantics of the reply strings
in the plugin case though.

> 
> Then we have ONE very straightforward plain C session management API, no
> reason for app authors to reject implementing it, and implementations of
> it do not affect those who have implemented the API.  In the process
> we'd have solved the same problem for plugins, which needs doing anyway.
> 
> -dr

-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language