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 importantThis 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!
