On Sun, Nov 22, 2009 at 05:21:07AM +1100, Patrick Shirkey wrote: > > 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.
yeah. it was a bit annoying in lash, that you needed to poll on a separate fd in order to get your notifications. this approach takes advantage of the jack client thread, so you dont need to look for it in your mainloop. however: save is invoked from a different thread. so this is still not totally easy. > > > > > 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? depends on how big the state is... but fwiw the notification callbacks are executed sequentially in the current implementation. -- torben Hohn _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
