[LAD] LADI

Patrick Shirkey pshirkey at boosthardware.com
Mon Dec 21 10:10:55 UTC 2009


On 12/21/2009 08:45 PM, alex stone wrote:
> You have no disagreement from me in any of the points you've made.
>
>    


Thinking back there was an agreement from Stephane and Torben that they 
would not expect either to either work on jack_session for jack2. 
However I don't recall Stephane explicitly stating that he had an 
objection to jack_session being integrated into jack2. Simply that he 
would not be the person to do it and that Torben didn't want to work 
with c++.

Given that the actual code proposed by Torben is incredibly simple 
compared to the mental effort it took to come up with the implementation 
I don't see how it will not be integrated into jack2 at some point in 
the not too distant future.

I definitely don't recall Paul saying anything about it not being 
accepted to jack1 trunk. I have assumed his lack of communication to be 
tacit agreement that it is a viable addition to the codebase.

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 
Fons is doing some pretty custom stuff with the system that he runs and 
is more than capable of contributing code that would disable 
jack_session if it was not made a compile time option (which is is 
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 
considering that he is now suggesting that he will not even release his 
version of session management I really have an objection to his 
objection being given priority over the rest of us who support 
jack_session as a viable option.

Unless there is something that I have missed over the passed two weeks, 
I think it is time for a vote on the issue if there really is no 
consensus between the major stakeholders.

As far as I can tell it boils down to this:

jack1. Torben has provided a test case and code for integration.
jack2. No one has offered to integrate Torbens work yet.

jack_session adds 4 or 5 additional callbacks to the code base. It 
allows for simple session management to be handled within jack with 
minimal code needed on the client side. It can be integrated with LADI 
realtively easily and Nedko has offered his support for making that 
happen. Additionally there is a potential for a new non realtime thread 
to be added to the server for handling session requests to enable things 
like undo and application renaming when loading sessions while an 
existing session and/or app is running.

 From a normal users perspective we would need to have an interface that 
gave us the options:

- killing already running  apps before loading a session
- attempting to rename the apps without restarting them
- load a new jack instance and connect it with netjack

I see this interface being similar to the firefox recover session 
interface but others may think of better ways to handle/present the options.





Patrick Shirkey
Boost Hardware Ltd





> Alex.
>
> On Mon, Dec 21, 2009 at 9:34 AM, Patrick Shirkey
> <pshirkey at boosthardware.com>  wrote:
>    
>> On 12/21/2009 08:22 PM, alex stone wrote:
>>      
>>> This is probably because the Jacksession version would need to
>>> maintained in a seperate branch, and so we'd have 3 versions of jack
>>> to deal with.
>>> I tested jacksession, and it works well. (Using the experimental branch)
>>> As Torben says, there's minimal intrusion in apps, and importantly
>>> minimal change to the jack API.
>>>
>>> I'm sorry to see it stop, but Torben's been driving this forward, as a
>>> practical opportunity for users, and not just a lot of discussion, and
>>> if he feels the politics (and i think that is what's at the heart of
>>> this) of doing this outweighs the positive benefits, then i can hardly
>>> blame him for freezing it indefinitely or otherwise. Why keep bashing
>>> your head against the wall?
>>> If he decides to pick this up again, and take it further, then i'm
>>> willing to continue testing, as i see jacksession as the simplest,
>>> most elegant, and least intrusive session management system i've seen
>>> to date. That's i guess, the best we can do for now.
>>>
>>> The users will have to wait, find another way, or just accept it's not
>>> going to happen.
>>>
>>>
>>>        
>>
>> I haven't seen anything on the lists that implied or suggested that
>> jack_session would not be applied to Trunk once it was decided it was
>> ready for wider testing.
>>
>> I have been expecting that to happen and am quite surprised that Torben
>> has decided to freeze development. Is there some debate on irc that I
>> have missed in the past two weeks?
>>
>> Just cos one person has strongly objected to it doesn't mean it
>> shouldn't be made an optional feature for the rest of us to have access
>> to. It can always be disabled at compile time.
>>
>> It doesn't add  bloat, it can be integrated with LADI, it is just a few
>> additional callbacks, it's simple to integrate and it enables at least
>> 80% of functionality for a normal users session management requirements.
>> I would like to find out if it the remaining 20% is even needed by the
>> majority of users.
>>
>> IIUC the current implementation is only missing support for undo. There
>> are a couple of proposed options for the other issue of handling
>> application naming conflicts. Any one of those options if implmented
>> will be better than we have now.
>>
>>
>>
>>
>>
>> Patrick Shirkey
>> Boost Hardware Ltd
>>
>>
>> _______________________________________________
>> Linux-audio-dev mailing list
>> Linux-audio-dev at lists.linuxaudio.org
>> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>>
>>      
>
>
>    



More information about the Linux-audio-dev mailing list