JackWishList

JACK is an excellent audio subsystem supporting low-latency, real-time audio routing in a modular, multi-application environment. However, it does have some outstanding issues which limit its usefulness. This page notes and discusses those issues.

Per Port Meta-Data

The utility of this feature is obvious. It should be possible for each port to have any number of Key=Value pairs associated with it. Example uses include: port grouping (this would make e.g. making higher order Ambisonics connections much easier), port range hints (does this port only accept CV (DC voltage)? Floats in some range other than -1:1?, meter values, etc.

A simple API addition of jack_port_get_metadata() and jack_port_set_metadata() would suffice.

References:

Is Linux Audio moving forward?

http://drobilla.net/files/jack_metadata.h

Per Client Meta-Data

Just like the port metadata, but at the client level. Uses include: BASE64 encoded application icons, URIs for alternate communication channels (such as an OSC URL), client status information, session manager hints.

Arbitrary Port Types

Generic Message Ports

Conceptually, there should be two basic types of port contents: Continuous and Intermittent. Continuous ports, like audio, might have a property of sample-rate in the future. Intermittent ports, like MIDI, are message/packet based. The JACK API should be enhanced to reflect this and allow applications to define their own port types, which must derive from the Continuous or Intermittent base types. An example of a port type deriving from Continuous would be Control Voltage. An example port type deriving from Intermittent might be OSC, or Single Float.

Port types could be expressed by interned URIs. For example: "uri://jackaudio.org/port-types/ControlVoltage."

A connection manager could read these port types make it obvious to the user that ports can only be connected to others of matching type.

Let me re-iterate that these types must be extensible and defined by the client applications not baked into the JACK API like the current MIDI implementation is.

References:

JACKiOS client data API

Arbitrary variable length message payloads

JACK has no need to know the format of message contents. All it needs is to know the message source, destination, type (interned URI), timestamp, length, and blob contents. With such a framework, MIDI can be transported by JACK in the same way as OSC, JSON, LV2:ATOM, XML, or any other damn message encoding somebody comes up with in the future--all without requiring any further changes to the JACK API.

Non Real-Time Messages

The solution to this problem would also be the solution to the MIDI SysEx problem. Sometimes there is a need to send large messages which have no requirement of being delivered in real time. It is undesirable to attempt to transmit these messages over the same channel as RT messages. It should be possible to implement this side-channel communication transparently to the message API (perhaps via an additional RT flag, or automatically based on message length).

Client Rename

There is a need (especially in the case of session managers) for an API function in JACK to rename a client. jack_client_set_name() or jack_client_rename() are appropriate options. Patches for this exist, but have not made it into mainline JACK. The current workaround involves saving all client connections, unregistering with JACK, registering with the new name, and attempting to restore connections--which is slow and unreliable.

References:

Status of Session Handling

The Situation(s) with JACK

64-bit nframes_t

Apparently having only 32-bits of timeline resolution was enough of a barrier that Ardour had to add 64-bit timestamps for its internal sync mode... How about adding a 64-bit position to the JACK transport so that everyone can benefit?

Shared Tempo Map

Currently, things like tempo ramping and seamless looping are impossible to implement correctly, because only the Timebase Master knows the entire tempo map--other clients only discover it during playback--when it's already too late to make preparations. A shared tempo map, perhaps facilitated by a metadata API, would allow all clients to know when to expect tempo changes.

(locked)

This work is licensed under a Creative Commons License