21 Dec
2009
21 Dec
'09
9:02 p.m.
On 12/22/2009 11:35 AM, Gabriel M. Beddingfield wrote:
We have at least 3 options on the table for dealing with this.
The argument continues either way afaict ;-)
On Tue, 22 Dec 2009, Patrick Shirkey wrote:
Don't you mean Fons here? Stephane has already provided support for dbus
in jack2.
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
We can add a non realtime thread.
* process call graph must be halted during the
session callback (a consequence of not being
asynchronous).
Also handled by a non realtime thread.
Also, I wasn't comfortable with how the
serialization should work...
but it was too early in the process to pick nits on that.
I haven't seen any specifics on that aspect until now.
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.