Sync is unstable when new JACK clients enter or exit

[jamshark70]

Preparing for a video tutorial on Link sync and SuperCollider, I did this:

1. Start jack_link.
2. Start Ardour (empty project with metronome enabled, as a click track).
3. Start VCV Rack (patch connects Stellare Link's Reset trigger to a short tone).
4. Run the JACK transport.
5. Rack sounds late -- this is expected because Stellare Link requires the user to tune latency compensation by hand -- so I tweak the "offset" knob until sync is OK.
6. Now I boot the SC server. This creates a new JACK client.

At this moment, the Link timeline slows and sync is lost: the barline on the JACK transport no longer corresponds to the barline in Ardour, Rack or SuperCollider (and they all seem to be slightly different offsets).

If I sync SC and Rack without jack_link, then I can boot and reboot the SC server (creating and destroying JACK clients) at will, without disrupting the Link timeline.

So I have to conclude that jack_link is doing something unnecessary.

For my demo, I think I can be careful to have all JACK clients running the whole time. Or I may simply not use jack_link at all (a pity, because I wanted to show it hooked up to a DAW). But something isn't right here.

Are you using forceBeatAtTime()? Ableton recommends against it.

[rncbc]

the barline on the JACK transport no longer corresponds to the barline in Ardour,

that is probably a sign that ardour, as a jack client I presume, is not even syncing to jack-transport; and what about which jack client is timebase master? are they all (ardour, rack and sc) trying to be?

Are you using forceBeatAtTime()? Ableton recommends against it.

yes, I know and that's been actually intended, to have it sync to precise beat times, at least with qtractor; you can of course try whether having requestBeatTime() instead gets it to a better result in your case. please

[grammoboy2]

Might be interesting so see what happens if you replace Ardour with Qtractor.

[jamshark70]

that is probably a sign that ardour, as a jack client I presume, is not even syncing to jack-transport

It definitely is, at least at first, if I set everything up in a precise order.

and what about which jack client is timebase master?

This seems to be a fairly common misconception about Link. By design, Link establishes no master clock. The Link peers cooperate to converge on a shared timeline.

I suspect this is the root of the trouble here. If JACK transport expects to be the master clock, that's at odds with Link's design where any/every clock should be able to make micro-adjustments to keep together with the shared timebase. But, if JACK transport clients expect the transport to be sample-accurate consistent, then JACK transport must not adjust. I'm guessing this is why it's using forceBeatAtTime: to avoid adjusting. (I bet if you try to run two JACK transports on separate machines, with jack_link on both machines, it would be messy.)

So it may simply not be possible to make JACK transport and jack_link work in the Link way.

What surprised me is that adding/removing JACK clients seemed to disrupt JACK transport. Maybe that's a JACK bug and not a jack_link bug.

Not sure about qtractor. If I have time later I might try it.

[grammoboy2]

I don't think you can change the tempo of Ardour, but from Ardour itself. IIRC it doesn't accept a tempo change of jack_transport from a other Jack Tranport master. https://tracker.ardour.org/view.php?id=8095

[jamshark70]

After some more tests, I think the central problem is that JACK transport just can't go along with the Link way. jack_link can't override JACK transport's behavior, so it can never be a polite Link peer.

Qtractor handles it better than Ardour, but still not completely stable.

Test A:

1. Launch Qtractor, set the transport to follow JACK.
2. Start jack_link.
3. Start the transport.
4. After this, when adding new Link peers, JACK transport's timing hiccuped and I could never get it back into musically usable sync. This was both with forceBeatAtTime and requestBeatAtTime.

Test B (this one really highlights the difficulty):

1. Launch SC, start a LinkClock, and run a metronome.
2. Launch Pd, open a patch using abl_link~, and run a metronome. Good sync.
3. Open Qtractor.
4. Start jack_link.
5. Start JACK transport.

At this point, two things happen depending on the Link function being called:

• forceBeatAtTime: SC and Pd both jump immediately to the barline. If they are playing sequences at that moment, this could be anywhere from mildly to severely disruptive. (In SC, it may result in synth nodes that never release, for instance.)

• requestBeatAtTime: SC and Pd continue on their way and JACK transport doesn't sync.

Link's specification here is that peers should begin in phase with the shared timeline. For JACK transport, that means, if I click "play" 1.5 beats into the bar, JACK transport should either begin playing immediately from 1.5 beats into the bar and not from the bar line, or it should wait until the next bar line to start playing. JACK transport doesn't know anything about Link, so it doesn't care what anybody else is doing, and jack_link has no power to make it care.

I'm guessing Paul Davis would not be receptive to suggestions to change JACK transport for better Link cooperation (Link means sacrificing sample accuracy and perfect timeline continuity)... so it's probably better just to document that jack_link may work under specific situations (set up all peers and start the JACK transport before playing anything in other software -- but even here, tempo changes failed badly) but probably shouldn't be relied on in production.

[rncbc]

there's an alternative: https://github.com/x37v/jack_transport_link please test whether it fares to jack_link.