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

Le 12 déc. 2011 à 21:30, Paul Davis a écrit :

> On Mon, Dec 12, 2011 at 11:15 AM, Stéphane Letz <[hidden]> wrote:
> 
>> You are basically describing the current state of JACK2 *minus* some parts....
>> 
>> Do you really want to start a JACK3 project with a new implementation ??
> 
> Not really.
> 
> But I also don't expect you to agree with the reasons why neither
> Torben or myself were willing to "migrate" to Jack2. The fact that
> Jack2 is written in C++ doesn't alter the fact that things that ought
> to be simple to add or extend there simply are not. Both of us have
> gone to add things to Jack2 and found ourselves bewildered by the
> class architecture. This is expected in the much more spaghetti-like C
> code of Jack1, which lacks on ability to inherit functionality across
> classes. But part of the reason to endorse a C++ implementation was to
> make things much more modular, and although Jack2 superficially looks
> that way, in practice in seems not to be.
> 
> If you want to commit to ensuring that Jack2 will provide all the
> functionality listed, and whatever else the user base comes up with,
> then fine, those of us who have issues with the codebase in Jack2 can
> just walk away and leave it with you (to some extent we already are,
> because of your support for and work on the OS X and Windows ports).
> But I think that (a) you probably don't want to make that committment
> and (b) the JACK community would be better served by an implementation
> on which more people were willing to work. As it stands, we're never
> likely to see the work Torben has put into alsa_in/out appearing in a
> more integrated form as the Jack2-style "adapters". This is just one
> example.
> 
>> I don't know what to say more...
> 
> Apparently, these items from my list escaped your attention:
> 
>>   full memory locking when platform supports it
>>   memory use for ports proportional to number of ports
>>   no fixed limit on number of ports
>>   multiple device support handled by server (from Jack2, but
> with  the quality of alsa_in/alsa_out)
>>   realtime device switching (without stopping/restarting server)
>> single header file tree, for use by jack1, jack2 and anything else
>> single tool dir tree, for use by jack1, jack2 and anything else
>> **proposal** use Boost widely to accelerate development and
> leverage existing work.
> 
> You're also ignoring the need to have a single netjack streaming
> protocol, moving D-Bus interaction into a separate component so that
> it is on the same level as any other protocol.
> 
> These are not small issues, though some of them are not "hard coding" problems.
> 
> Do you have some alternate proposal for how to address the issues I
> opened this thread with?


1) I'm happy to see that after something like 6 years (LAC 2005 was the first presentation on jackdmp model), most of the ideas developed at that time: like parallel graph execution, click-free connection/disconnection, 2 threads models on client side... are finally understood and accepted.

2) I'm happy to see that new ideas done after : like the 2008 control API model and development of Nedko, DBus control access, realtime device switching (without stopping/restarting server), done in 2009-2010... finally reach some acceptance.

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.

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. 

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.

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.

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

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.

Grame also developed the JackOSX package, at set of additional components to be distributed on OSX to improve experience for CoreAudio applications users on OSX. In particular we wrote the JackRouter CoreAudio/JACK bridge component to allow any CoreAudio application to become a JACK client.

On Windows, Grame developed the JackRouter ASIO/JACK bridge component to allow any ASIO application to become a JACK client.

8) Grame wrote some useful additional code: JACK API testing code and server timing profiling code, 

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.

Paul, at some point you'll have to make some choices. Nobody can be happy at the same time. Choose the right horse.

Stéphane 

1323727136.27719_0.ltw:2,a <07331126-8480-4C55-A066-AE000999356F at grame dot fr>