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

  On 12/09/2011 12:43 PM, Paul Davis wrote:
> This is my list of fundamental requirements for the next stage of JACK:
/me perks up
> * the JACK 1.0 API must be defined first
> * it must clearly, unambiguously and incontrovertibly be the successor
> to Jack1 and Jack2
>       - this probably means that it must emerge relatively quickly
> once/if work begins on it
> * it cannot assume that Stephane will stop working on Jack2 or that
> myself will stop working on Jack1, or that anybody else will stop
>        working on anything else at all BUT it hopefully will lead to a
> union of efforts.
"Hopefully lead to a union efforts," imo, should be "MUST lead to a 
union of efforts." Personalities and preferences be damned. Whatever 
comes out of this won't be unambiguous successor to Jack1 and Jack2 if 
developer efforts continue to be divided.

Maintaining sets of patches on the side isn't a problem, but we can't 
have >1 mainline anymore. (I guess that's what you mean below when you 
say "single tree for header files.")

> * it must recognize that neither Jack1 nor Jack2 are likely to just
> "die", so any plans must include them to some extent.
> * it must provide a single soname (ABI, effectively) that identifies
> any implementation and can be used by packagers and app developers
> * every feature of Jack2 and Jack1 that people agree is worth
> retaining should be available
> * it must not increase and should preferably decrease replicated
> developer effort
> * it must be API and ABI compatible with current JACK releases
> * it must run on Windows, OS X and Linux and preferably Solaris and
> the BSD family
> * it should make possible end-user features that are agreed to be important
/me applauds
> This is what I think the future looks like:
>
> Features
>
>      C API/ABI
>      C++ implementation
>      synchronous mode (server waits for all clients)
>      asynchronous mode (slow clients have no impact)
>            - possible to avoid zombification, always
>      parallel graph execution
>      click-free connection/disconnection
/me applauds
>      full memory locking when platform supports it
>      memory use for ports proportional to number of ports
>      no fixed limit on number of ports
>      2 thread execution in libjack (from Jack2; one for process, one
> for other callbacks)
>      multiple device support handled by server (from Jack2, but with
> the quality of alsa_in/alsa_out)
>      full control protocol
>      full support for device sharing with PulseAudio
/me applauds louder!
>      realtime device switching (without stopping/restarting server)
>
> Desirable features to be merged from outside JACK "core"
>
>     1 streaming network protocol, for LAN and WAN use, with zeroconf
> discovery or similar
>     bridges/routers for platform specific APIs (ALSA (pcm&  MIDI),
> CoreAudio, CoreMIDI, winMIDI, ASIO, other?)
>     control protocol access from (at least) D-Bus, perhaps others
>         - probably via helper components; not built into server but
> possibly loaded by it.
>
> Development Prerequisites
>
>    build system: waf
/me leans forward in his seat, applauding still more loudly!
>    source code management: git
>    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.
>
> User Interface
>
>    single session manager app that can also be used to start/stop/configure JACK
>    existing control apps (qjackctl, patchage, etc) continue to be options
Standing ovation!

(I request that the control app expose more of the functionality of Jack 
(specifically Netjack, along with other modules) directly. That's 
something that will come with time.)

Yours,
David Nielson

1323546854.18206_0.ltw:2,a <4EE3B8D8.2010708 at comcast dot net>