[LAD] adding session notifications to jack

Patrick Shirkey pshirkey at boosthardware.com
Sat Nov 21 18:21:07 UTC 2009

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

More information about the Linux-audio-dev mailing list