[LAD] adding session notifications to jack

[Patrick Shirkey]

On 11/22/2009 04:49 AM, 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.
>    


Or not documented in a way that made it explicitly clear to a mortal 
developer how to implement it quickly and correctly.



> 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 );
>
>
> 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.
>
> i have also changed jack_client_open which is able to accept a client
> specified unique id. (this must be used when reloading state, so that
> clients can be found again
>
> so... a potential session handler is still required. and it needs to be
> able to query the portconnections.
> in order to restore them.
>
> 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.
>
> then a pure alsa client would also need to link to libjack and create a
> jackclient with no ports and no process callback, in order to
> participate in session handling.
>
> i dont see a difference. it just links to "some" session handler lib.
>
> 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.
>
> so far i have only patched oom and ardour. and ardour doesnt quit yet,
> when requested.
>
> well... tell me what you think :)
>
>
>    



I like the simplicity of the approach.  FWIW, I would find it 
straightforward to implement.

Would there be any issues with 20 different apps saving state at the 
same time?





Patrick Shirkey
Boost Hardware Ltd