[LAD] adding session notifications to jack
pshirkey at boosthardware.com
Sat Nov 21 18:21:07 UTC 2009
On 11/22/2009 04:49 AM, torbenh wrote:
> 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
> 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
Boost Hardware Ltd
More information about the Linux-audio-dev