On Sat, 2009-11-21 at 18:49 +0100, torbenh wrote:
What is jack_session_event_t?
> by calling jack_session_notify() the session callbacks of the listening
What is this unique ID? Unique ID of what?
> so... a potential session handler is still required. and it needs to be
This could simply be implemented as another jack client, though, right?
> but clients are not required to have an extra dependency in order to
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
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.
Linux-audio-dev mailing list