Re: [Jack-Devel] The Situation(s) With JACK

PrevNext  Index
DateTue, 13 Dec 2011 14:22:06 +0100
From Stéphane Letz <[hidden] at grame dot fr>
ToPaul Davis <[hidden] at linuxaudiosystems dot com>
CcJACK <[hidden] at lists dot jackaudio dot org>
In-Reply-ToPaul Davis Re: [Jack-Devel] The Situation(s) With JACK
Follow-UpPaul Davis Re: [Jack-Devel] The Situation(s) With JACK
Le 13 déc. 2011 à 00:29, Paul Davis a écrit :

> On Mon, Dec 12, 2011 at 4:59 PM, Stéphane Letz <[hidden]> wrote:
> 
>> 3) You and Torben seems to have problems with the C++ class model of JACK2. It seems some others can at least accomodate:  Nedko was able to add the (purely written in C) control API,  Romain Moret added the NetJack2 stuff, Devin Anderson did the awesome job of rewriting the entire MIDI backend part, at lot of others over the years sent code improvements, cleanup and C++ class restructuring patches...etc... See the JACK2 ChangeLog quite long "contributors" section. All of them should be thanked for all their great work that make the code base better, mode robust and more easily maintainable.
> 
> Absolutely. And as I said, if there is one person or a team of people
> who want to step up and say "we will take responsibility for not just
> maintaining JACK but continuing to improve it", I'm entirely happy to
> get out of the way. The problem is that in the experience of actual
> users, Jack1 and Jack2 each have some distinct benefits, so neither
> one is really redundant.

Could we first precisely describe that?

> In addition, despite the contributions of
> many people to both Jack1 and Jack2, at present it does not appear
> that there is any real energy from anyone to do anything substantive
> about the list of issues that I mentioned. If that assessment is
> wrong, and Grame and/or some other group of people are willing to
> "take JACK and run with it", that would be great. I just can't see
> that happening, given the history of the last couple of years.

Part of the problem was a lack of clear vision for the future of the code base : what is supposed to be the code base reference to be worked on?

> 
>> 4) I'm not against removing from the *official* tree some parts like the NetJack2 work, that (as I told you privately recently) is now something that we at Grame want to play with for our own needs. Note that NetJack1 has been added in JACK2 tree since something like 2 years. If the community wants NetJack2 out of the tree, then it will need some work for us to "detach" in a maintainable way, but it can certainly be done. But I will not put any energy into NetJack1maintenance.
> 
> Totally understandable, and also totally indicative of why we have a
> problem in this area. But ... see my prior response to Tobias. I don't
> really care what the solution is, we just need to be able to provide
> good, clear, simple solutions to users' needs.

Assuming we can define a "common minimal set of needed features": can we describe that?

> 
>> 5) Better control API "exposure" as a separated protocol or component can certainly be done. Back in summer 2008, the JACK dev community had this painful discussion that finally went nowhere. But I think the work could be restarted.
> 
> jackd.py in the jack1 tree is a working proof-of-concept already of
> providing a D-Bus <=> Control API that is separated from the server
> itself, so in that sense, the work has already been restarted. Its
> just that its come to a halt again.
> 
>> 6) Multiple device support handled by server : no clear idea for now (note that this seems really like a ALSA issue), but I don't see why it could not be done in current JACK2 code base.
> 
> Its not an ALSA issue. Its about a framework the server to allow
> streaming to/from other devices with the same quality of sync that
> alsa_in/alsa_out currently provides for ALSA devices, along with the
> other options that those tools provide. Neither Jack1 nor Jack2 really
> have a framework right now to allow this in a user-centric way.

My point is that I'm not sure this framework makes sense outside of the ALSA context, since for instance CoreAudio does "multiple device aggregation" at a lower level. But I may be wrong. And anyway the needs have to be refined. I don't have a clear view of them. Do you?


> 
>> 7) Full support for device sharing with PulseAudio : is it something new compared to what is correctly implemented in JACK2?
> 
> No.

OK.

> 
>> 7) Multiple OS support and bridges/routers for platform specific APIs (ALSA (pcm & MIDI), CoreAudio, CoreMIDI, winMIDI, ASIO:  up to now and AFAICS Grame is the *only* developer/maintainer/tester of OSX and Windows specific code base (with some recent contributions by John Emmas for Windows). Grame wrote the CoreAudio backend, Grame wrote the first version of CoreMidi backend (later improved by Devin Anderson). Grame wrote the first version of WinMME backend (later improved by Devin Anderson). Grame wrote the PortAudio backend for Windows (supporting every API PortAudio supports, that is WinMMe, DirectSound, ASIO). Grame wrote a Solaris version in 2008.
> 
>   [ ... and more ... ]
> 
> I don't wish to ever write anything that fails to acknowledge the
> ENORMOUS impact that the work you and others at GRAME have had on
> JACK. The list of things is at least as you have written here,
> arguably longer. JACK would not exist as a cross-platform system
> without your work, and it would almost certainly lack the many other
> great features that Jack2 has developed and refined. Even if I did the
> original implementation of JACK, it is almost certainly true today
> that more people are using an implementation that you created and have
> maintained, developed and extended over many years.
> 
>> I think this gives now a more precise view of the situation as seen by Grame. We keep fully interested in multi-OS support. If the new proposal is not really a new implementation, I still don't see what is it exactly. Without any new developers working on "non" Linux parts, I don't see how the new proposal can succeed.
> 
> Me neither. So do you have an alternative that doesn't require that?
> Or do you believe that the list of problems I gave at the beginning is
> not really a list of problems (or at least, that the ones that are
> worth solving do not require any significant coding) ?

1) We have to list  "Jack1 and Jack2 each distinct benefits"

2) We have to choose what is the reference code base

3) We have to establish a plan for the reference code base to evolve until it reach the list of expected features.

Stephane 
PrevNext  Index

1323782522.10272_0.ltw:2,a <6AEBD5DE-FAB0-4400-BE6C-1A306E4199C0 at grame dot fr>