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

Le 9 déc. 2011 à 19:43, Paul Davis a écrit :

> This is my list of fundamental requirements for the next stage of JACK:
> 
> * 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.
> * 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
> 
> 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
>    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
>    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
>  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

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 ??

I don't know what to say more...

Stéphane 

1323706524.27164_0.ltw:2,a <0A9FA904-C9D9-4367-AE7C-F2EB0AC25FCC at grame dot fr>