[LAD] jack client autoconnection

Kjetil S. Matheussen k.s.matheussen at notam02.no
Mon Feb 4 15:25:33 UTC 2008



On Mon, 4 Feb 2008, Bob Ham wrote:

> On Mon, 2008-02-04 at 15:14 +0100, Kjetil S. Matheussen wrote:
>> On Mon, 4 Feb 2008, Bob Ham wrote:
>
>>> Even less hassle is for clients to do nothing at all and leave the whole
>>> business entirely for jackd.  I suggest the following function instead:
>>>
>>>  int jack_set_autoconnect(jack_client_t *, int autoconnect);
>>>
>>> This enables a control interface that can present the user with a simple
>>> system-wide toggle switch that would dictate whether or not ports are
>>> automatically connected.
>>>
>>
>> I'm not sure what you mean by the last sentence.
>> Is the "autoconnect" variable either 0 or 1?
>
> Yes, sorry.  The "int autoconnect" parameter would be a boolean
> indicator; 1 to enable autoconnecting, 0 to disable it.  It would
> probably be sensible to have a complementary jack_get_autoconnect()
> function to return the value as well.
>
>> But how do libjack know the order of ports? By just
>> using creation order? Well, I guess that will work.
>
> Indeed.  This is how most client-side autoconnecting seems to work at
> the moment.  Clients simply get "a list" of hardware ports from the
> server and connect them in sequence against the client's own ports.
>
>> How about this interface then?
>>
>> void jack_enable_autoconnect(jack_client_t *);
>> void jack_disable_autoconnect(jack_client_t *);
>>
>> And then a typical playback client would work like this:
>>
>> jack_client_t *client=...
>> jack_enable_autoconnect(client);
>> jack_port_t *out_port[0]=jack_port_register(client,...);
>> jack_port_t *out_port[1]=jack_port_register(client,...);
>> jack_disable_autoconnect(client);
>
> Sorry; I obviously wasn't specific enough about the semantics of the
> toggle function.
>
> What I am suggesting is not to toggle autoconnecting for individual
> clients, but to toggle autoconnecting for *all* clients, globally.  The
> flag that gets toggled would be a property of the engine, not the
> client.
>
> In terms of autoconnecting, clients would do quite literally nothing at
> all.  The above code would be rewritten as follows:
>
> jack_client_t *client=...
> jack_port_t *out_port[0]=jack_port_register(client,...);
> jack_port_t *out_port[1]=jack_port_register(client,...);
>
> Clients would never call the new function unless they were control
> interfaces, eg. QJackCtl, a jack_autoconnect CLI program, or some
> gnome-jack-autoconnect-switch applet.
>
> This removes from client authors the burden of implementing
> autoconnection, and enables a convenient interface for controlling
> autoconnect behaviour.
>


Thanks for clearing up. But I'm pretty sure your idea is too
simple. We also need a way to create ports which are not
autoconnected.

The ideal way, if we follow this thread of thinking, would
be to add another type of jack_port_register function, which
does not autoconnect:

jack_port_register_no_autoconnect(client,...);

However, this new API will break a lot of current programs
which are using the old jack_port_register function instead.
Infact I don't think there is any (sane) way to make your
proposal work without creating lots of mess with ports
in old programs who are autoconnecting when it shouldn't.




More information about the Linux-audio-dev mailing list