On 12/22/2009 12:39 AM, Gabriel M. Beddingfield wrote: > > > On Mon, 21 Dec 2009, Patrick Shirkey wrote: > >> The only person I can recall who had an explicit objection to it was >> Fons, who said he would stop using jack if it was accepted. Given that > [snip] >> anyway). I don't think he should be allowed to make the decision for >> the rest of us about what is accepted to trunk and what is not. Also > > I recall a few people agreeing with Fons. Plus, Fons is so frigging > thorough that... what should we write? "Yeah!! What he said!" Hardly > an important contribution to the discussion. > > Also, with the reception that Fons got, I'm sure there were a few like > me who kept their mouths shut unless they had something important to > contribute. > > Anyway, FWIW, I agreed 100% with Fons... and IIRC he was open to > having an in-JACK session management API provided that it played nice > with a larger, more comprehensive session manager. (I.e. partial > session loading/saving, no client renaming, etc.) >
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? While Fons is thorough with his criticism which is to be respected as it helps to refine the knowledge base and code, that should not mean that the option of having jack_session available for the rest of us to use is completely off the table. We just need to be aware of the limitations. 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 advanced managers. In fact Nedko even offered his support/interest for making LADI work with jack_session. Being that LADI is real and publicly released that should hold more weight than Fon's views on the matter. 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. Patrick Shirkey Boost Hardware Ltd _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
