[Jack-Devel] stepping down

[Paul Davis]

On Sun, Jan 31, 2016 at 8:37 AM, Christian Schoenebeck <
schoenebeck at crudebyte.com> wrote:

> On Sunday 31 January 2016 14:44:42 Paul Davis wrote:
> > > I don't think Jack is the wrong solution for a DAW either. But Jack
> never
> > > got finished.
> > > It has a wonderful API, but it shouldn't be a struggle for a program to
> > > create a jack client
> > > if a jack server isn't running. (there were a lot of talk about this
> > > around 10 years ago,
> > > but the end result never became as good as it should I think).
> >
> > i am not sure what the problem is here. if the client doesn't specify
> > anything, then the server will start automatically with the same
> parameters
> > as it did last time. this has worked for years. no?
>
> Well, it worked for many, but it also had confusing aspects for many
> users, on
> Linux at least.
>
> Anyway, IMO many proposed useful features never made into JACK due to
> generalization concerns. JACK's general design concept was always "it's
> just a
> server with a set of buffers being passed around, JACK does not know or
> care
> what the content of the buffers is". And this fundamental design barrier
> was
> defended over years, which caused it to age.
>

i don't think that this isn't accurate.

(1) JACK *has* to know what the data is because it has to (potentially) mix
it. this has always been true.
(2) adding new data types to JACK is a relatively simple matter from the
perspective of jackd and libjack. It isn't simple for applications/clients,
which have to deal with the possibility of ports of "odd" types.



>
> Generalization of software is good for developers, but real value for
> users is
> added by adding customizations for the main purpose it is used for. And the
> main purpose of JACK is distributing audio signals with audio applications
> and
> audio devices, not distributing RSS feeds between coffee machines.
> Accordingly
> important features for that purpose, like the ability to control the gain
> factor of audio connections should IMO be incorporated directly into JACK.
>

this is VASTLY less important than global latency management. almost every
client that writes data to a JACK port has a gain control somewhere in the
path that leads to the port, and manages gain for its own reasons. but very
few clients (if any) can truly manage latency issues, and i have reversed
my original position on this (which used to be that clients should do it).


>
> Another internal deficit was the policy how to deal with laggy clients.
> Which
> is quite important for consumer use cases. Instead of simply kicking out a
> laggy client from the signal graph it would be better to handle it like
> CoreAudio does: that is automatically increasing the latency instead.
>

given that jack2 (the most widely used implementation) still doesn't have
automatic/builtin MIDI bridging, as well as no easy way to use multiple
devices, i think that's a much less important issue (particularly since
jack2 doesn't kick clients out under almost any circumstances at all.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.linuxaudio.org/archives/jackaudio/attachments/20160131/05c236fa/attachment.html>