Re: [LAD] LADI

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
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Tue Dec 22 04:15:03 2009