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 _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
