[LAD] LADI

Patrick Shirkey pshirkey at boosthardware.com
Mon Dec 21 22:54:29 UTC 2009


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







More information about the Linux-audio-dev mailing list