De toekomst van JACK

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!

De toekomst van JACK

4 thoughts on “De toekomst van JACK

  1. hell yeah !
    ik hoop echt dat dit eindelijk komaf maakt met alle varianten en externe tools enz die rond jack hangen. Jack is een super tool maar veel mensen blijven er liever vanaf om dat het _zo_ verwarrend kan zijn om de boel te configureren.
    x-platform + zero-config audio over network = super om linux bak aan mac te linken (kan nu ook maar vergt toch wat config werk)

    hopelijk krijgt hij voldoende gehoor en slaagt hij erin om iedereen mee te krijgen en alle neuzen in dezelfde richting te laten wijzen.
    (nu ja, als Paul dat niet kan dan is er weining hoop voor linux audio vrees ik)

  2. Nou zo te zien komt er helemaal niks uit. De mensen van GRAME geven geen millimeter toe, Torben Hohn is zo te lezen ook flink gedesillusioneerd en Nedko heeft een poging gewaagd maar krijgt geen respons. Ik denk dat het tijd wordt Jack1 te ditchen want daar zit klaarblijkelijk sowieso geen toekomst meer in.

Leave a Reply

Your email address will not be published. Required fields are marked *