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@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev