21 Dec
2009
21 Dec
'09
8:35 p.m.
On Tue, 22 Dec 2009, Patrick Shirkey wrote:
So you agree with Fon's statement that if the
jack_session code is
accepted you would not want to use jack1 any longer and would support a
fork or stop using it completely and create your own realtime audio daemon?
Probably about as much as you agree with Stéphane's threat
to do the same over dbus (which, IIRC, is closely related to
the session management debates). :-)
I must have missed the part of the debate where it was
agreed or even
defined that jack_session would not be able to play nicely with more
Here's a few with the most recent proposal:
* save/restore requires application to shut down and
restart.
* session callback does not work asynchronously
* process call graph must be halted during the
session callback (a consequence of not being
asynchronous).
Also, I wasn't comfortable with how the serialization should
work... but it was too early in the process to pick nits on
that.
As far as I can tell the design process broke down
mostly because one
person made a strong case for not having any other form of session
management except the one that he is working on (and is now saying he is
not interested in releasing publicly) and consequently wound the other
parties up to the point where they decided it was too frustrating or
stressful to discuss it any further at that point.
Once it's in the JACK API, it won't be coming out.
Likewise, changing it will be very difficult after the
fact... so it needs to be right.
If it's not in the JACK API, there is no argument.
-gabriel