[Jack-Devel] stepping down
schoenebeck at crudebyte.com
Sun Jan 31 14:37:13 CET 2016
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.
More information about the Jackaudio