Re: [Jack-Devel] ladish + jack autoconnect

Robin Gareus <[hidden]> writes:

> On 12/25/2011 12:22 AM, Nedko Arnaudov wrote:

>> I'd like to implement new jack1 server option (exposed in jackd too) with
>> value that defaults to current behaviour. The option (kind of enum) has
>> four other possible values. In total:
>> 
>>  * dont restrict self connect attempts (default)
>>  * ignore (dont fail, nop) all self-connect requests
>>  * fail all self-connect requests
>>  * ignore self connect requests to other clients only
>>  * fail self connect requests to other clients only
>> 
>> If something in my proposal is not clear, please let me know. I'll try
>> to clarify it.
>
> That clarified a lot regarding the state of ladi. Thanks!
>
> As for adding this option to vanilla JACK. I'm rather skeptical. I think
> this rather works around client-bugs or problems that should be fixed in
> the respective clients.
>
> Too many options make trouble-shooting issue with JACK a pain.

IMO few(?) other options we already have are much rarely used and
less useful.

> My first reaction is that this proposal does not add anything to jack
> and thus is not relevant in the core. But I did not give it too much
> thought. Is there a good use-case - except for working around b0rked apps?

> OTOH I did not investigate how many jack-clients would be affected and
> how much it'd improve usability in the real-world with potentially lots
> of messy clients.

Its for b0rked apps. Some major ones like ardour2 do it. Essentially
all-in-one apps tend to implement session manager functionality. And
this creates interoperatability problem. We don't have unified way to
tell apps to not self-connect. But we can give the power to the user to
cut them at the hub - the jack server.

Telling the user that app X must be fixed to add option for disabling
self-connect is almost always not acceptable. Because the user has no
direct and easy control over app X development and deployment of app X
in distro Y.

In my, yours and maybe of others opinion fixing clients is the right
thing to do. But the app author may disagree. Or distro packagers may
disagree. This is social problem or rather a virtue. The opposite is
stalinism. People have right to disagree. User must be in control of
his system. Trying to implement totalitarian society by penalizing users
is bad idea.

This does not mean that systems with predefined, fixed and specialized
workflows should not be developed.

>>> On that note: is ladish/laditools compatible with qjactctl these days?
>> 
>>> The OP mentioned that he starts jackd via qjackctl and and last time I
>>> checked, that was incompatible with ladish. Is that still true? Can they
>>> co-exist or inter-operate?
>> 
>> No two sesion handlers/managers (pyjacksm/qjackctl/lash/ladish) are
>> known to interoperate. Do you see point of doing go so? If so, how? 
>
> No.
>
>> Or maybe you used "compatible" in some other meaning?
>
> Primarily I wanted to confirm if someone starting jackd (compiled w/ladi
> patches) via qjackctl would experience the /self-connect/ problems that
> were described in the original "alsa_in problems" thread.
>
> ..and then pondered wider ramifications:
>
> It may well be that distributors allow users to install multiple
> jack-session handlers/managers along with one of the (3,4? [2])
> available implementations or configurations of jackd. The user can
> choose at run-time which of the session managers to start/use and
> potentially start/stop more than one.

I think this matches the reality.

-- 
Nedko Arnaudov <GnuPG KeyID: 5D1B58ED>

1324773286.16602_0.ltw:2,a <878vm132wv.fsf at arnaudov dot name>