Re: Server control plug-ins proposal

Hi,

I've tested the controlplugin branch at
9c8728a6a00923b7dbcecb1da632a8fe9da89010.

I get no messages in the log file at all.

At some earlier version (93a9f176212cce84799258df6064e1b789068934) I had
messages in the log file but server settings are not read. I had the
dummy driver used. This is very strange because I have alsa driver
selected in both setting files, ~/.config/jack/conf.xml and ~/.jackdrc

I think it is still the case but I cant be completely sure because I
have no log anymore :(
What I can see through wmladi is that I get "wrong" latency used and no
realtime being used.

I still dont get how this plugin stuff helps. Instead of "jackdbus auto"
process you get "jackd -C dbus" process.

Let me match the controlplugin branch status against problems I've
identified in my original guardians/rebels mail:

> 1. jackdbus uses different settings storage. Because guardians like the
> way it works for them, they are not fascinated about this. Rebels
> however clearly see that jackdrc format was a mistake. It is not
> settings format but a shell script (and some guardians use it like
> shell script). Moreover jackdrc format is not hierarchical. It does not
> allow multiconfigs. OTOH having JACK settings in two places is BAD. If
> one has mixed jackd+jackdbus system, both will be used. Simple convert
> during a transistion is not fixing the problem because both jackd and
> jackdbus are installed on the system.

Now it is even worse. I get wrong settings used even when they are right
in both places. May be this is just a little bug somewhere though.

> 2. Two widesread applications, ardour and qjackctl write jackdrc
> directly. This desecrates the tradition that assumes jackdrc file is
> written by a human and is read by the software. Also it implies race
> condition because there is NO read/write locking mechanism
> used. jackdrc reader may get inconsistent data during write. Two
> simultaneous writters may corrupt the file.

Not solved.

> 3. Two widesread applications, ardour and qjackctl launch jackd
> manually. Thus they can't start JACK server if it is implemented
> differently. Thus they can't start JACK server in a LADI (jackdbus)
> system.

Not solved too. They start jackd without "-C dbus", thus laditools and
other jackdbus control apps dont see the jack server as running but they
see the other jackd instance, the one with "-C dbus" and it reports the
wrong state of the jack virtual studio.

> 4. When qjackctl is not used, guardians tend to check whether server is
> running by checking for running jackd process through ps or some
> process monitor like htop. This will not work when they are in the
> dbus rebel's camp because there may be jackdbus process but this is not
> a proof that jack server is running.

Not solved. "jackd -C dbus" and "jackdbus" both suggest that jack is
tainted by the dbus daemon and both are not indication whether jack
server is running.

> 5. Some guardinas are not happy with the fact that multiprofile setup
> is not possible with jackrc format. They clearly need this feature even
> if they dont like the dbus heresy.

If I got it right, not solved. Probably not topic of the controlplugin
branch though.

> 6. Some guardians are not happy with the fact that dbus rebels give
> some gifts to their followers. They want these gifts to be universal
> and available even to tradition piligrims.

If I got it right, not solved either. But maybe controlplugin
refactoring somehow will allow this. I have no strong opinion here
because I want multiple "studio abstractions" available as part of the
jack virtual studio. Current plan for the abstractions of studio setups
is to implement them as lash sessions that are loaded before loading the
normal lash session, be it song composition setup, recording setup for
particular song or live play setup.

I'd find it much more useful if veto stuff gets more push. It will ease
virtualization of the jack connections and thus will be one step toward
virtual studio setups.

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>


_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org