Re: [LAD] adding session notifications to jack

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
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev