[LAU] A year of Linux Audio revisited - would like to know your oppinion

Paul Davis paul at linuxaudiosystems.com
Fri Dec 14 08:07:20 EST 2007

On Thu, 2007-12-13 at 21:57 -0800, Robert Persson wrote:
> Paul Davis wrote:
> >
> > JACK has a number of problems, some of them significant. The things
> > you've spoken about are not among them.
> >
> >
> >   
> While I take the point that my understanding of what is going wrong when
> I run jack is incomplete, what you have just told me is effectively: The
> problems you claim to be experiencing are not happening. This kind of
> thing is not a good basis for communication between developers and users.

No, the problem here is that you comments are midway between a technical
user and a completely new user. You have opinions about the nature of
the user interface, specific features you think the system should have,
and ideas about what matters with respect to its adoption for specific
kinds of work, but at the same time, you want to plead "i am not a
programmer" etc. Rather than simply observe behaviour and say "this
doesn't work for me" or "this breaks the following workflow", you chose
to get into the details of "this is how to fix jack". your assumption is
that since you know what appears to be broken, you also know what needs
to be fixed. this might seem like an obvious corollary, but i can assure
you that afters years of writing software, it simply isn't true.

I don't think, as you claimed, that you are being thoughtless in posting
what you did. But I am also not being disrespectful in my response. 

So, lets go over it again:

   1) the problem with JACK configuration is, to the best of my
knowledge, ALWAYS caused by either incorrect system configuration (i.e.
no authorization for the user to user realtime scheduling or memory
locking, in turn caused by incorrect setup or the wrong version of PAM
or its equivalent) OR by the use of specific hardware that requires
different defaults than the ones JACK picks on its own. Problems in the
first category are NOT solvable by JACK - they can only be solved by
distributions (or users if they want to try it). Problems in the second
category: well, here is where JACK could maybe do a better job and
automatically pick a better set of defaults. However, at this point this
is hard to do - there is no simple way for us to identify which hardware
requires different values. So, once again, this is a problem that
doesn't lie entirely within JACK's domain. It is also not clear to us

   2) latency configuration - when JACK was designed, we understood that
for a number of applications, responding to changes in the buffer size
would be difficult. we also understood (perhaps incorrectly) that most
users did not need to do this. as time has gone by, and people have
grown comfortable with JACK and/or a new set of users with different
workflow requirements, a different perspective has crept in. JACK has
the technical ability to alter the buffer size on the fly, and most
clients will handle it. However, most *control* applications do not
provide a way to do so. Is this an error in JACK? If you see JACK as a
finished ecosystem that should just work for the user, then sure. If you
see JACK as a technology that can be used in a number of different ways,
and allows different control apps to be created for it, then not really.

> I'm sorry if you thought I was being thoughtless posting what I did. I
> know that jack has great potential and that it already allows you to do
> some fantastic things. I want linux audio to succeed. 

me too. but this can't happen in the way that a lot of people expect.
there is no dictator of linux audio. this is no like apple, where they
could say "CoreAudio is the API you will all use, now get busy". linux
audio, perhaps for better and perhaps for worse, is a ragtag collection
of individuals, APIs, technologies etc. its not some uniform, unified,
cohesive system, which is simultaneously its biggest strength and its
biggest weakness.

> If something is
> making it impossible even for me to work with it then it will certainly
> be a big barrier for someone who cares less about free software. That's
> why I believe I should speak up. Jack not working properly is one such
> obstacle for me. 

That's correct. But blaming JACK for not working properly is an obstacle
for us. JACK developers do not control the full context in which a user
uses JACK. If we did, JACK would Just Work (TM) for everyone. But we
don't, and its a problem for us when every single day on IRC i hear from
users like you who expect JACK to work, find it does not, and blame

> Unfortunately I also have to say that being told to
> RTFM is another.

If only there really was a manual to FR.

More information about the Linux-audio-user mailing list