Robin Gareus robin at gareus.org
Tue Sep 20 12:25:37 UTC 2016

On 09/20/2016 01:40 PM, Patrick Shirkey wrote:
>> On 09/20/2016 07:03 AM, Patrick Shirkey wrote:
>>> Because netjack isn't good enough
>> correct.
>> jack can have a single timebase master and likewise netjack has a single
>> net-master.
>> Ableton-Link is decentralized: Multiple performers can interact with
>> each other on an equal level (no master/slave semantics).
>> It's not groundbreaking tech. Laptop orchestras and the likes have used
>> similar techniques since a while, but all prior-art that I know is ad-hoc.
>> As far as I know this is the only protocol concerning *musical-time*
>> that's spec'ed out, has a cross-platform reference implementation and
>> potential to find its way into hardware.
>> Feel free to criticize the protocol on a technical level or hunt for
>> bugs in the implementation ... or simply ignore it silently.
> So then the next question would be is there any reason NOT to integrate it
> directly into JACK?

There's an existing feature request already: [1]

JACK cannot be slaved to anything. jackd is always master, so there's a
conceptual conflict.

Closest concept is jack-timebase master [2]. A client can provide
musical-time to jack and thereby to all jack clients that support jack

So yes, there are some reasons to not *directly* integrate it, but like
existing jack tools [3] (jack_lsp, jack_connect, jack_transport,...) it
could be included with jack one way or another. Seamless integration is
possible. It just needs someone to do the work.

Rui already has a working standalone prototype (no timebase support yet,
but it's a good start).

There are also some technical details to be sorted out: e.g. the current
Link reference implementation requires C++11, jack-tools are C89... but
those are details.


[1] https://github.com/jackaudio/jack2/issues/231
[2] http://jackaudio.org/files/docs/html/group__TransportControl.html
[3] https://github.com/jackaudio/tools

More information about the Linux-audio-dev mailing list