The Situation(s) With JACK

classic Classic list List threaded Threaded
130 messages Options
1234 ... 7
Reply | Threaded
Open this post in threaded view
|

The Situation(s) With JACK

Paul Davis
It has come time to address the situation with JACK.

This widely-used and innovative project has stalled out and is causing
as many headaches for users (potential and actual) as it is helping.
Lets take an honest and harsh look at the problems:

1. there are at least 3 different implementations of JACK. This is not
a problem in and of itself, but in the real world, it contributes the
remaining problems in real ways.

2. there is no defined API version that clients can be said to depend
on (that is, libjack from different implementations of JACK do not
come with a standard soname that can be used in dependency
determination). In addition, JACK's attempted use of weak linkage to
deal with an evolving API turns out to be based on a serious
misconception on Linux (it does work on OS X, and sometimes on Linux
too).

3. there is widespread confusion about the relationship between Jack1
and Jack2, with an overwhelming number of people believing that Jack2
is the newer, better version of Jack1.

4. JACK was one of the first audio APIs to provide network streaming,
but the existence of two incompatible implementations of netjack makes
network streaming more to difficult to explain than it is to actually
do. Both implementations have their benefits, but there is absolutely
no talk of any unification and some notable resistance to it. When the
typical question arises "Can I use JACK to stream audio from A to B?"
the answer is so complex that many people just give up (and probably
rightly so). Contrast this to, for example, using the AUNetSend and
AUNetReceive plugins on OS X. It just makes a mockery of netjack in
terms of ease of use (though latency is terrible).

5. after seven or eight years, the API still has not reach version 1.0.0

6. largely as a result of (2), distributions and applications are
starting to create a situation where despite the fact that Jack1 and
Jack2 are, in fact API and ABI compatible, explicit requirements for
Jack1 or Jack2 are in effect. They are wrong to do so, but their
reasons for doing so are entirely understandable.

7. any new extensions to the JACK API (such as an upcoming metadata
proposal from David Robillard and myself) require duplicated effort
across different implementations, which is silly and not very
productive.

8. Dangling features such as interactions with multiple devices have
totally different implementations in Jack1 and Jack2, with notable
drawbacks in each case. Where Tschak solves them, it does so having
effectively dying as an unreleased private project.

9. Despite the presence of JACK Session support in a number of notable
applications, many developers apparently feel that it is unfinished or
incomplete or in some other way not worth using "at present"

10. The existence of LADISH continues to produce confusion for users
wondering how best to do some of the things that LADISH does, because
there are now other ways of doing them.

11. Interaction with PulseAudio continues to be a nightmarish headache
for a large number of new JACK users.

12. By adopting jackdbus, distributions have sanctioned a way of using
of D-Bus that was explicitly disavowed at LAC Berlin. This also isn't
a problem in and of itself, but it has created a situation where
(almost) all interaction between JACK and everything else that is
accessible via D-Bus is the responsibility of Nedko, with whom I now
have a severely antagonistic relationship and several other people
have a ... difficult ... relationship. I take as much blame for the
relationship part as anyone else, but it remains the case that JACK
interacting with other parts of Linux via D-Bus is a good idea that is
currently limited by the entire constellation of issues surrounding
jackdbus. Torben has already demonstrated an alternative
implementation (jack.py) that follows the guidelines set up at LAC
Berlin, but it remains a small, experimental project barely used by
anyone.

13. The only people to do work on JACK development over the last
couple of years confine themselves to specific versions of JACK, and
despite nominally friendly communication, do not really collaborate
with the others. (Note that I am including myself in this).

In summary, although Jack1 and Jack2 continue to provide useful
functionality to users and the overall design of the API continues to
have many fans and a relative elegance, the *project* as a whole is in
a serious condition.

I blame myself for some important parts of this situation. When
Stephane originally wrote jackdmp as an experiment with
multi-core/parallel support and other important ideas, it was decided
by the JACK group meeting at LAC Berlin that jackdmp would become the
successor to jack1. Instead what happened was that Jack1 and Jack2
have continued to evolve in parallel, largely because the primary
maintainers/developers of Jack1 (Torben and myself), while respectful
of the ideas that Stephane designed in jackmp, find the actual
implementation to be something we don't wish to work with. At no time
have I, as the supposedly benign dictator of the project, put my foot
down and said "this has to stop", because it seems wildly
inappropriate. Stephane (and others) are totally free to continue
their work, and distros are totally free to pick whichever
implementation they wish. Nedko has continue to work on Jackdbus and
LADISH, and has seen his work widely adopted by many distributions.
Torben has been free to do a completely new implementation ("tschak")
which merges jack1 and jack2 features/design. I can't stop that, and
I'm not sure I want to - these efforts have been incredibly valuable
as research projects and providing useful functionality.

But ... this freedom has come at quite a high cost for the user
(particularly the potential user) community, as detailed above. For
developers, its not so bad - the different implementations are, in
fact, API and ABI compatible, and the issues with netjack are
invisible to clients. The dithering around with
LASH/LADISH/JackSession and the core design issues that they represent
should have been solved years ago and weren't, which does impact
developers a bit, but for most its a "use it/don't use it" choice that
doesn't really affect them, only those users who want to use one of
LADISH/JackSession for some purpose.

A few weeks ago, I had an extremely negative IRC interaction with the
maintainer of the JACK plugin for audacious. Some of what this person
said was based on ignorance and incomplete understanding, but at the
root of his complaints and observations were a few perfectly valid
criticisms of JACK as a project (rather than as a technology) And so
now ....

                                    It Has To Stop.

I do have a proposal for how this is going to stop, but before I put
it forward, I would like to first see if there are any other ideas
floating around on the mailing list that have not come up when I've
discussed this situation on IRC. Once any discussion about this email
settles down, I'll outline my proposal (whatever it ends up being at
that point).

This is a decision that affects users, packagers, distributions,
developers and other people. Despite a radically innovative (and,
thanks to Stephane, cross-platform) design and unmatched
functionality, the project needs a change in direction in order to
live up to its potential. If it can live up to it, then JACK will be
the simple, natural, functional choice for audio and MIDI on all 3
major OS platforms including network streaming, and the confusion and
stagnated development that it embodies now will be a thing of the
past. If it can't, JACK will continue to be a useful tool, but will
likely slowly rot. Lets try to avoid that if we can.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: The Situation(s) With JACK

Scott Lavender-2
I am glad to read this email.

I have felt that JACK seems to have diffused the scope of the project
by having multiple versions and different implementations.  Or perhaps
the gestation of the various version/implementations has diffused the
scope.  Either way, I believe JACK can be more effective and more
widely embraced by re-evaluating the goals, scope, and audience of the
project.

This re-evaluation might even mean removing "features" that do not
serve the scope of core project.  And perhaps the removed
functionalities could reintroduced as plugins, add-ons, or even
_other_ projects.

From a user and distribution perspective (with especial interests in
new users) I would like to see JACK more focused simplifying user's
experience.  Users will not ultimately care about how powerful or
functional JACK is if the threshold to usage is too high.

ScottL
Ubuntu Studio Project Lead
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: The Situation(s) With JACK

Mark Constable
On 09/12/11 01:21, Scott Lavender wrote:
> I am glad to read this email.

Yes indeed, absolutely wonderful. Thank you Paul.

May everyones peace pipe be as long as need be to birth... JACK3!
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: The Situation(s) With JACK

Adrian Knoth
In reply to this post by Paul Davis
On 12/08/2011 02:04 PM, Paul Davis wrote:

> 11. Interaction with PulseAudio continues to be a nightmarish headache
> for a large number of new JACK users.

I'm somewhat curious about your upcoming proposal and if it will address
this particular issue.

> I do have a proposal for how this is going to stop, but before I put
> it forward, I would like to first see if there are any other ideas
> floating around on the mailing list that have not come up when I've
> discussed this situation on IRC.

Is there a log of this conversation?


> If it can live up to it, then JACK will be the simple, natural,
> functional choice for audio and MIDI on all 3 major OS platforms
> including network streaming

This sounds like a big promise, and I'd love to see this thing fly.


Can't wait for your proposal.


Sorry, nothing to argue with your e-mail so far. ;)


Cheers
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: The Situation(s) With JACK

Stéphane Letz
In reply to this post by Paul Davis
>
>                                    It Has To Stop.
>
> I do have a proposal for how this is going to stop, but before I put
> it forward, I would like to first see if there are any other ideas
> floating around on the mailing list that have not come up when I've
> discussed this situation on IRC. Once any discussion about this email
> settles down, I'll outline my proposal (whatever it ends up being at
> that point).
>
> This is a decision that affects users, packagers, distributions,
> developers and other people. Despite a radically innovative (and,
> thanks to Stephane, cross-platform) design and unmatched
> functionality, the project needs a change in direction in order to
> live up to its potential. If it can live up to it, then JACK will be
> the simple, natural, functional choice for audio and MIDI on all 3
> major OS platforms including network streaming, and the confusion and
> stagnated development that it embodies now will be a thing of the
> past. If it can't, JACK will continue to be a useful tool, but will
> likely slowly rot. Lets try to avoid that if we can.

I suggest that you just post your proposal.

Stéphane

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: The Situation(s) With JACK

Paul Davis
On Thu, Dec 8, 2011 at 12:55 PM, Stéphane Letz <[hidden email]> wrote:

> I suggest that you just post your proposal.

just as a general observation, this is something to keep in mind:

          http://xkcd.com/927/
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: The Situation(s) With JACK

Devin Anderson
In reply to this post by Paul Davis
On Thu, Dec 8, 2011 at 5:04 AM, Paul Davis <[hidden email]> wrote:

> 1. there are at least 3 different implementations of JACK. This is not
> a problem in and of itself, but in the real world, it contributes the
> remaining problems in real ways.

From a JACK driver perspective, it certainly makes things difficult.
For a few months now, I've been tempted to port the 'alsarawmidi'
slave driver to JACK 1, and each time I start, I think about
maintaining two sets of code that do the same thing in two different
languages with two different driver APIs, become frustrated, and find
something better to do with my time.

> 7. any new extensions to the JACK API (such as an upcoming metadata
> proposal from David Robillard and myself) require duplicated effort
> across different implementations, which is silly and not very
> productive.

This applies to the driver problem too.

> 13. The only people to do work on JACK development over the last
> couple of years confine themselves to specific versions of JACK, and
> despite nominally friendly communication, do not really collaborate
> with the others. (Note that I am including myself in this).

This too.

> I do have a proposal for how this is going to stop, but before I put
> it forward, I would like to first see if there are any other ideas
> floating around on the mailing list that have not come up when I've
> discussed this situation on IRC. Once any discussion about this email
> settles down, I'll outline my proposal (whatever it ends up being at
> that point).

Back in July, you said this:

> what *should* have happened was a plugin API that as many developers
> as now use JACK would have agreed to adopt.
>
> what could have happened was something like JACK.

LV2 looks better to me all the time.  I had reservations about LV2
because of the lack of transport sync, but the new 'time' extension:

    http://lv2plug.in/ns/ext/time/

... seems like an elegant solution to the transport problem.

I'd personally like to see momentum shift to LV2.

I'll go out on a rather shaky looking limb and say that I'd like to
see JACK become a library that is used to route audio and MIDI data
'inside' an application (e.g. between plugins), and continues to
provide bindings to hardware.

--
Devin Anderson
devin (at) charityfinders (dot) com

synthclone - http://synthclone.googlecode.com/
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: The Situation(s) With JACK

Stéphane Letz
In reply to this post by Paul Davis

Le 8 déc. 2011 à 19:15, Paul Davis a écrit :

> On Thu, Dec 8, 2011 at 12:55 PM, Stéphane Letz <[hidden email]> wrote:
>
>> I suggest that you just post your proposal.
>
> just as a general observation, this is something to keep in mind:
>
>          http://xkcd.com/927/


OK, but please just be concrete Paul!

Stéphane
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: The Situation(s) With JACK

Paul Davis
On Thu, Dec 8, 2011 at 1:17 PM, Stéphane Letz <[hidden email]> wrote:

> OK, but please just be concrete Paul!

I'm really not trying to be evasive. I'd just rather wait till more
people comment here to see if I change my mind. I'm also contemplating
using an innovation management website to set up and collect rankings
and opinions on different ideas. It helps that I'm working on one
right now ;)
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: The Situation(s) With JACK

Stéphane Letz
In reply to this post by Devin Anderson
> I'll go out on a rather shaky looking limb and say that I'd like to
> see JACK become a library that is used to route audio and MIDI data
> 'inside' an application (e.g. between plugins), and continues to
> provide bindings to hardware.
>
> --
> Devin Anderson
> devin (at) charityfinders (dot) com`

Hugh ?? So basically you don't have understood the *basic* real power of JACK ?? What make JACK so *unique*?

I just can't believe that.... ((-;

Stéphane
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: The Situation(s) With JACK

Harry van Haaren
In reply to this post by Paul Davis
On , Paul Davis <[hidden email]> wrote:
>          http://xkcd.com/927/

Yes. It is something that passed my mind also, good its already been brought up.

Looking forward to the proposal also, -Harry
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: The Situation(s) With JACK

Hermann Meyer
Am Donnerstag, den 08.12.2011, 19:22 +0000 schrieb
[hidden email]:
> On , Paul Davis <[hidden email]> wrote:
> >          http://xkcd.com/927/
>
> Yes. It is something that passed my mind also, good its already been
> brought up.
>
> Looking forward to the proposal also, -Harry

Yep, really hope that all jack(s) could be merged back into one main
project, . .

also looking forward to the proposal

hermann

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: The Situation(s) With JACK

dehnhardt (Bugzilla)
In reply to this post by Paul Davis
Am Donnerstag, 8. Dezember 2011, 08:04:57 schrieb Paul Davis:
> It has come time to address the situation with JACK.

Dear Paul,

about a year ago I decided to start making music again - and decided to use
Linux.
I must admit - I had a hard time to get my setup working - although I'm a
devloper and so I don't hesitate when it comes to debugging.
A lot of problems results from being unsure which jack/mp/dbus works/works
best with ffado and later how to get lash/ladish running.

It took me nearly a year but now I can say that it's stable. But I agree that
anyone without a technical background woukd have given up long before.

As a result: I REALLY APPRECIATE your serious attempt here!
The combination of jack, random audio application and something that keeps all
together (ladish) is unique (afaik) and great! (If we only could have this
flexible routing inside an audio application as well...)

I will be glad to help wherever I can!

Hoilger
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Σχετ: The Situation(s) With JACK

Panos Ghekas
In reply to this post by Hermann Meyer
Hi everyone,
Please accept a word from a humble windows user of Jack, basicaly a very simple setup here to "merge" audio from any of my vast array of virtual instruments and effects :-)

I'm reading every post on this list for almost two years now, though not on Linux and trying to learn as much as I can.

Agree with Paul that many times things go complicted for the simple Jack user and agree as Hermann and others said that a one sole project would be great and as simpler as posssible of course.
Things went messy at some point as I can judge from the e-mails sent, so I agree with Paul's descriptions and reasons :-)

Lookin' forward for the proposal too.

Best to all
Panos


Απο: hermann <[hidden email]>
Προς: JACK <[hidden email]>
Στάλθηκε: 9:31 μ.μ. Πέμπτη, 8 Δεκεμβρίου 2011
Θεμα: Re: [Jack-Devel] The Situation(s) With JACK

Am Donnerstag, den 08.12.2011, 19:22 +0000 schrieb
[hidden email]:
> On , Paul Davis <[hidden email]> wrote:
> >          http://xkcd.com/927/
>
> Yes. It is something that passed my mind also, good its already been
> brought up.
>
> Looking forward to the proposal also, -Harry

Yep, really hope that all jack(s) could be merged back into one main
project, . .

also looking forward to the proposal

hermann

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org



_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: The Situation(s) With JACK

Paul Davis
In reply to this post by dehnhardt (Bugzilla)
On Thu, Dec 8, 2011 at 2:55 PM, Holger Dehnhardt
<[hidden email]> wrote:
> Am Donnerstag, 8. Dezember 2011, 08:04:57 schrieb Paul Davis:
>> It has come time to address the situation with JACK.
>
> Dear Paul,
>
> about a year ago I decided to start making music again - and decided to use
> Linux.
> I must admit - I had a hard time to get my setup working - although I'm a
> devloper and so I don't hesitate when it comes to debugging.

I need to stress that at this point in time I'm not terribly
interested in trying to solve the problems that JACK encounters that
are inherently hard (for example, exploring the n-dimensional
configuration space of your audio interface to find good settings to
use by default).

My concern is over the problems we have created through the
development process (or lack thereof).

Thanks for reminding me about FFADO. Another problem.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: The Situation(s) With JACK

ewb-asi
In reply to this post by Paul Davis
On 09/12/11 02:04, Paul Davis wrote:
> It has come time to address the situation with JACK.
< list of 13 points>
>
>                                     It Has To Stop.
> the project needs a change in direction in order to
> live up to its potential. If it can live up to it, then JACK will be
> the simple, natural, functional choice for audio and MIDI on all 3
> major OS platforms including network streaming, and the confusion and
> stagnated development that it embodies now will be a thing of the
> past.

Hear hear!

I'm a long time (mostly) lurker on this list.

My role at AudioScience includes maintaining the ALSA driver for our
soundcards.

As it happens, one of my current tasks is to "make it work better with
JACK".  This has higher priority than "make it work better with
pulseaudio, etc", because we see JACK as the key enabler for pro-audio
apps on Linux, and hope it continues to be so.

I look forward to your proposals, without underestimating how hard it
may be actually make changes.

--
Eliot Blennerhassett
AudioScience Inc.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: The Situation(s) With JACK

Fons Adriaensen-3
In reply to this post by Paul Davis
On Thu, Dec 08, 2011 at 08:04:57AM -0500, Paul Davis wrote:
 
>                                     It Has To Stop.

What can I say ? For at least the last five years or so
Jack for me 'just works'. Honestly, I can't remember the
last time I had any problem with it. Maybe that is because
I stay away from obese desktops or anything that tries to
hide or automate system configuration. I may wish it had
some features that it hasn't, or the inverse, but that is
a different subject. It just works.

And yes, a lot of effort is probably wasted in maintaining
epx(1) versions.

I've no idea what direction your proposal will take.
One option would be to restart from scratch, to define
and implement a 'next generation' Jack that could be
quite different from the current one, and that could
replace it in say a year or so. In that case I do have
some ideas. But I suspect that is not your intention.

One good reason to have a fresh look at what Jack is
supposed to do is the fact that SMP systems are more
or less the norm today. And complex apps (A3 being
the prime example) are taking advantage of that and
organising their internal processing using multiple
threads. No doubt more will follow. Yet, scheduling
in Jack remains on a per-process basis. That means
that e.g. if app B depends on input from app A, the
entire B is made to wait until all of A has done its
work, while the actual dependencies may be much more
fine-grained. There are several ways to address this.
One would be to have a single 'audio engine' process
and delegate all audio processing to it. That would
of course mean that all security is lost, a single
rogue audio routine could bring down everything.
Another solution would be to make Jack trigger port
or groups of ports instead of a process. So anything
in B that depends on A would run as soon as all output
from A that a part of B depends on is available. In
other words, the signal graphs becomes global. That
would also allow B to be a insert of A without adding
latency etc.

But I'm dreaming.

Ciao,

--
FA

Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: The Situation(s) With JACK

Nedko Arnaudov
In reply to this post by Paul Davis
Hi,

Paul Davis <[hidden email]> writes:

> It has come time to address the situation with JACK.

Good news is this!

> This widely-used and innovative project has stalled out and is causing
> as many headaches for users (potential and actual) as it is helping.
> Lets take an honest and harsh look at the problems:
>
> 1. there are at least 3 different implementations of JACK. This is not
> a problem in and of itself, but in the real world, it contributes the
> remaining problems in real ways.

Non-technical issue. Lot of people (including myself) will benefit from
solving this one. I cannot judge whether it is possible to really fix
this problem. For sure the situation can be improved by growing
friendlier social environment.

> 2. there is no defined API version that clients can be said to depend
> on (that is, libjack from different implementations of JACK do not
> come with a standard soname that can be used in dependency
> determination). In addition, JACK's attempted use of weak linkage to
> deal with an evolving API turns out to be based on a serious
> misconception on Linux (it does work on OS X, and sometimes on Linux
> too).

I've said this before and I'll say it again. IMO the API versioning
should be "split" based on features. Unfortunately libjack has no
library initialization function. jack_client_open() could be used for
this, by defining new jack_options_t bits. Given the multiclient uses
of jack though, it makes much more sense to introduce jack_init()
instead.

I'm talking about something like LV2 extension mechanism here.

IMO dereferencing a function pointer on each libjack API function call
will not introduce significant overhead.

> 3. there is widespread confusion about the relationship between Jack1
> and Jack2, with an overwhelming number of people believing that Jack2
> is the newer, better version of Jack1.

I agree that renaming jackmp to jack2 was idealistic attempt to unite
the jack development. Optimistic one as well.

> 4. JACK was one of the first audio APIs to provide network streaming,
> but the existence of two incompatible implementations of netjack makes
> network streaming more to difficult to explain than it is to actually
> do. Both implementations have their benefits, but there is absolutely
> no talk of any unification and some notable resistance to it. When the
> typical question arises "Can I use JACK to stream audio from A to B?"
> the answer is so complex that many people just give up (and probably
> rightly so). Contrast this to, for example, using the AUNetSend and
> AUNetReceive plugins on OS X. It just makes a mockery of netjack in
> terms of ease of use (though latency is terrible).
I'd speculate that this is same issue as (1)

> 5. after seven or eight years, the API still has not reach version 1.0.0

It will help if jack1 versioning is split from the jack API
"versioning". This implies requirement for wider consensus on the
API itself. Hopefully you are ready for this.

> 6. largely as a result of (2), distributions and applications are
> starting to create a situation where despite the fact that Jack1 and
> Jack2 are, in fact API and ABI compatible, explicit requirements for
> Jack1 or Jack2 are in effect. They are wrong to do so, but their
> reasons for doing so are entirely understandable.

I think that upstream should actively cooperate with packagers by giving
advice and writting guidlines. My attempt on is probably still in the
trac wiki.

> 7. any new extensions to the JACK API (such as an upcoming metadata
> proposal from David Robillard and myself) require duplicated effort
> across different implementations, which is silly and not very
> productive.

LV2-like extension mechanism can be linked to a plugin system. This
includes unified interface for drivers. I never got good reasoning why
driver API was not unified. I proposed this at some point and my
proposal was rejected.

> 8. Dangling features such as interactions with multiple devices have
> totally different implementations in Jack1 and Jack2, with notable
> drawbacks in each case. Where Tschak solves them, it does so having
> effectively dying as an unreleased private project.

It will help to get consensus what is the proper way of doing it and to
do it in all implementations. Given that there are no non-technical
issues here.

> 9. Despite the presence of JACK Session support in a number of notable
> applications, many developers apparently feel that it is unfinished or
> incomplete or in some other way not worth using "at present"

I don't see this as problem. The problem is that nobody actually has
motivation to work on solving the issues.

> 10. The existence of LADISH continues to produce confusion for users
> wondering how best to do some of the things that LADISH does, because
> there are now other ways of doing them.

You could explain how to do these things without ladish I guess. Its not
clear to me either. For various reasons in ladish I implemented things
that belong to JACK. But as we all know, the world is not perfect.

> 11. Interaction with PulseAudio continues to be a nightmarish headache
> for a large number of new JACK users.

We need someone with interest in both JACK and PulseAudio to fix this
mess. I doubt we will find volunteer for this. Maybe if some day one of
the mainstream distributions supported by commercial companies will pay
someone to fix this mess. A friendlier community is something that will
help again.

> 12. By adopting jackdbus, distributions have sanctioned a way of using
> of D-Bus that was explicitly disavowed at LAC Berlin. This also isn't
> a problem in and of itself, but it has created a situation where
> (almost) all interaction between JACK and everything else that is
> accessible via D-Bus is the responsibility of Nedko, with whom I now
> have a severely antagonistic relationship and several other people
> have a ... difficult ... relationship. I take as much blame for the
> relationship part as anyone else, but it remains the case that JACK
> interacting with other parts of Linux via D-Bus is a good idea that is
> currently limited by the entire constellation of issues surrounding
> jackdbus. Torben has already demonstrated an alternative
> implementation (jack.py) that follows the guidelines set up at LAC
> Berlin, but it remains a small, experimental project barely used by
> anyone.
It will help to clearly state what exacly was *disavowed*. After all
these years it is not clear to me what is wrong, in your (Paul) opinion
with jackdbus. The explainations changed several times so far. And then
the jack1 upstream acted against their claims. So I'm lost and
demotivated. Clear messages and technical level criticizms are needed
here. This applies to "the entire constellation of issues surrounding
jackdbus" statement too. I think i have a good telescope but it doesnt
translate other people thoughts into written text.

> 13. The only people to do work on JACK development over the last
> couple of years confine themselves to specific versions of JACK, and
> despite nominally friendly communication, do not really collaborate
> with the others. (Note that I am including myself in this).

Lack of friendly environment. Dictatorship instead of adoption or
rejection with sane explainations. I'm not talking only about jackdbus
here. There is a significant stack of jack1 (and sometimes jack2 too)
upstream decisions that doesn't make sense to lot of users and
developers/contributors.

14. multiclient apps. jack client (autore)naming.

> In summary, although Jack1 and Jack2 continue to provide useful
> functionality to users and the overall design of the API continues to
> have many fans and a relative elegance, the *project* as a whole is in
> a serious condition.
>
> I blame myself for some important parts of this situation. When
> Stephane originally wrote jackdmp as an experiment with
> multi-core/parallel support and other important ideas, it was decided
> by the JACK group meeting at LAC Berlin that jackdmp would become the
> successor to jack1. Instead what happened was that Jack1 and Jack2
> have continued to evolve in parallel, largely because the primary
> maintainers/developers of Jack1 (Torben and myself), while respectful
> of the ideas that Stephane designed in jackmp, find the actual
> implementation to be something we don't wish to work with. At no time
> have I, as the supposedly benign dictator of the project, put my foot
> down and said "this has to stop", because it seems wildly
> inappropriate. Stephane (and others) are totally free to continue
> their work, and distros are totally free to pick whichever
> implementation they wish. Nedko has continue to work on Jackdbus and
> LADISH, and has seen his work widely adopted by many distributions.
> Torben has been free to do a completely new implementation ("tschak")
> which merges jack1 and jack2 features/design. I can't stop that, and
> I'm not sure I want to - these efforts have been incredibly valuable
> as research projects and providing useful functionality.
jackdbus/ladish was never inteded as experiment. It was and still is
project with clear goals. Everything would have been much easier for
everyone if my efforts were criticized with reason and not faced with
negative emotions.

> But ... this freedom has come at quite a high cost for the user
> (particularly the potential user) community, as detailed above. For
> developers, its not so bad - the different implementations are, in
> fact, API and ABI compatible, and the issues with netjack are
> invisible to clients. The dithering around with
> LASH/LADISH/JackSession and the core design issues that they represent
> should have been solved years ago and weren't, which does impact
> developers a bit, but for most its a "use it/don't use it" choice that
> doesn't really affect them, only those users who want to use one of
> LADISH/JackSession for some purpose.
>
> A few weeks ago, I had an extremely negative IRC interaction with the
> maintainer of the JACK plugin for audacious. Some of what this person
> said was based on ignorance and incomplete understanding, but at the
> root of his complaints and observations were a few perfectly valid
> criticisms of JACK as a project (rather than as a technology) And so
> now ....
>
>                                     It Has To Stop.
>
> I do have a proposal for how this is going to stop, but before I put
> it forward, I would like to first see if there are any other ideas
> floating around on the mailing list that have not come up when I've
> discussed this situation on IRC. Once any discussion about this email
> settles down, I'll outline my proposal (whatever it ends up being at
> that point).
>
> This is a decision that affects users, packagers, distributions,
> developers and other people. Despite a radically innovative (and,
> thanks to Stephane, cross-platform) design and unmatched
> functionality, the project needs a change in direction in order to
> live up to its potential. If it can live up to it, then JACK will be
> the simple, natural, functional choice for audio and MIDI on all 3
> major OS platforms including network streaming, and the confusion and
> stagnated development that it embodies now will be a thing of the
> past. If it can't, JACK will continue to be a useful tool, but will
> likely slowly rot. Lets try to avoid that if we can.
I'm waiting for your proposal too. And I hope that it will improve the
unfortunate situation in the Linux Audio community. Make it a friendlier
place where people who disagree can cooperate. Where people when faced
with oposition try to adjust their views and try to create a product
that can serve a wider community. If we want this to happen, instead of
reducing scope and trying to control everything we should seek the path
to cooperation. To not burn bridges but to build them.

The rebel armies need home too, just like guardians need their temple.

--
Nedko Arnaudov <GnuPG KeyID: 5D1B58ED>

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

attachment0 (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The Situation(s) With JACK

Geoff Beasley-2
In reply to this post by Paul Davis
Having used all 3 jacks (jack1/2/tschack and jack-dbus = 4?) I can
attest that there are subtle differences in  performance and setup, so
it's certainly true that there are some substantial complications in
userland that have  plagued jack- however despite these drawbacks let's
not lose sight of jacks' remarkable power, stability, flexibility and
functionality. i doubt there is anything that can come close to it.


To me, it seems there is nothing really wrong with jack, it's more that
issues aren't being attended to when they arise. There are 4 'main'
developers, all of whom have firm views on direction and implementation-
hence the "forks" - and when a user makes
reports/observations/suggestions the dev "responsible" for "your" jack
is likely to respond but no one else will... therefore bugs and issues  
simply aren't being dealt with.

Now that Torben Hohn has ceased to develop (at least for the time being)
tschack no longer is a player- it's not even available anymore, so the
remaining dev's really have to sort out what they do agree on first, and
move from there. This is more a 'people' problem in the short term
rather than a technical one imho.

good to see this is at least out in the open ;)

g.


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: The Situation(s) With JACK

Jussi Laako-2
In reply to this post by Paul Davis
On 12/08/2011 03:04 PM, Paul Davis wrote:
> floating around on the mailing list that have not come up when I've
> discussed this situation on IRC. Once any discussion about this email
> settles down, I'll outline my proposal (whatever it ends up being at
> that point).

I'm still using jack1 and will hopefully have some amount of time
available in future to work again more on it.

I tried couple of times to join the IRC channel but seem to be still
banned from the channel, because of past issues of /me being busy and
freenode IPv6 connections being more than flaky...


        - Jussi
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
1234 ... 7