21 Nov
2009
21 Nov
'09
5:37 p.m.
On Sat, 2009-11-21 at 18:49 +0100, 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.
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 );
What is jack_session_event_t?
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.
What is this unique ID? Unique ID of what?
so... a potential session handler is still required.
and it needs to be
able to query the portconnections.
in order to restore them.
This could simply be implemented as another jack client, though, right?
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.
Personally I think it's pretty reasonable to expect Jack session
management to only support Jack things. Jack is portable to systems
where Alsa doesn't exist, for one thing. We have MIDI and bridges
between them, just keep the system clean, I say. The session manager
can deal with that crap if it wants to.
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.
I like the simplicity of this, but this last part is a problem. I'm not
sure doing this in Jack1 where all callbacks are in the process thread
is really appropriate. Then again, I don't think all callbacks being in
the process thread is appropriate, period ;) I guess this is just
another case of this error anyway, but an extremely bad one. You're
going to get a pretty severe drop-out saving a ton of stuff to disk in
the audio thread!!
But this leads me to the main point I want to make:
My take on this general thing is that a simple API like this is very
definitely the right path, but if anything I would like it not even tied
to Jack itself either. The reason session management has failed to take
hold is too much implementation-defined crap, breaking APIs, complexity
to implement, and all that kind of thing.
How about taking it one step farther: define this API in a single C
header, which would be very small, not tied to ANY implementation
whatsoever, and implementable by both plugins and hosts (this last part
is a very big win IMHO). All this header would define is a descriptor
(struct) with the necessary methods. Sort of a ladspa.h for session
management, except even simpler. How you actually get this descriptor
would be the only implementation dependent part (e.g. a host could pass
it to a plugin, or Jack could have a single new call to return it).
Then we have ONE very straightforward plain C session management API, no
reason for app authors to reject implementing it, and implementations of
it do not affect those who have implemented the API. In the process
we'd have solved the same problem for plugins, which needs doing anyway.
-dr