[Jack-Devel] stepping down

[Christian Schoenebeck]

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.

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.

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.

CU
Christian