Re: [LAD] jack client autoconnection

From: Kjetil S. Matheussen <k.s.matheussen@email-addr-hidden>
Date: Mon Feb 04 2008 - 17:25:33 EET

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.

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Mon Feb 4 20:15:02 2008

This archive was generated by hypermail 2.1.8 : Mon Feb 04 2008 - 20:15:02 EET