On Sun, Jan 31, 2016 at 8:37 AM, Christian Schoenebeck <schoenebeck@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.