On 12/22/2009 11:35 AM, Gabriel M. Beddingfield wrote: > > > 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). :-) >
Don't you mean Fons here? Stephane has already provided support for dbus in jack2. >> 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. We have at least 3 options on the table for dealing with this. > > * 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. The argument continues either way afaict ;-) _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev