Paul Davis heeft de knuppel in het hoenderhok gegooid, even afgewacht en vervolgens aangegeven welke kant hij het graag op zou willen zien gaan.

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

Het hele draadje kun je volgen via Gmane. Zou fantastisch zijn als er wat constructiefs voort zou komen uit de discussie. Mijn zegen heeft ie!