[Jack-Devel] Client-Server models are just fine. Please?

[tom at trellis.ch]

On Mon, February 1, 2016 15:49, Kjetil Matheussen wrote:
> On Mon, Feb 1, 2016 at 3:45 PM, David Nielson <david at naptastic.com>
> wrote:
>
>>
>> On 02/01/2016 08:31 AM, Kjetil Matheussen wrote:
>>
>>>
>>> I was thinking of a new configuration protocol where any libjack
>>> client can function as server.
>>>
>>
>> :|
>>
>>
>> why would you do that?
>>
>> Well, one reason is to force forward a formally defined configuration
>>
> protocol which is actually used. qjackctl would be forced to use this
> configuration, and the same with jackd. No more flaky use of sending around
> very informally specified strings via stdout and stdin as a communication
> protocol.

with all respect, the client/server model of jack seems well designed.

we could argue about the use of clients autostarting the server (with
semi-default and semi-custom settings in any jackdrc file), since if the
server doesn't run, nobody has started it explicitely thus the clients
can't work. if there are multiple choices of audio device to use, that is
HDMI, intel analog, external attached USB, firewire ..
i think the autostart feature is one of the pitfalls that made users see
many of the "could not start" messages. plus that there is some problems
with multiple sound servers wanting exclusive access to the device. other
issues are not mainly jack's problem, which is configuration of the system
(permit RT to to user, possibly use lowlateny kernel) and badly programmed
clients that behave one way or the other and can affect the server
operation as a whole. which again is a side-effect of this open ecosystem.
if i run a system with just jack, alsa, ffado and known-to-work clients
installed it works better than anything else.

building the gui into the server is surely not a good idea.

a recent "stock" install of a selection of jack tools showed no major
issues. it's a really mature ecosystem. if it doesn't change all the time,
this can be a sign of "close to finished" that again is what makes lasting
APIs useful. look at VST or any out-dated standards. one aspect these
plugins are still in use is that the API didn't change much.
compare it with PI, it didn't change much, is used in many formulas and
saying PI is dead is as funny as saying JACK is dead :)
greetings
tom