Re: [Jack-Devel] The Situation(s) With JACK
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. 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.
> 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.
> 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.
> 7) Full support for device sharing with PulseAudio : is it something new compared to what is correctly implemented in JACK2?
No.
> 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) ?
1323732550.31956_0.ltw:2,a <CAFa_cKkBZU-c42nDjZNXz1MhLa_UzOU4SSRtVWuQKQYKtCbRMQ at mail dot gmail dot com>