21 Dec
2009
21 Dec
'09
11:31 p.m.
On Mon, Dec 21, 2009 at 06:35:47PM -0600, Gabriel M. Beddingfield wrote:
On Tue, 22 Dec 2009, Patrick Shirkey wrote:
so you want it async ?
well... lets make it async then ?
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).
wrong.
Also, I wasn't comfortable with how the serialization should work...
but it was too early in the process to pick nits on that.
please state your problems.
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 _______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
--
torben Hohn