[LAU] [Bulk] Re: Jack transport - was - Ardour/Muse Jack tempo lock

[Tim E. Real]

On August 11, 2014 10:05:59 AM Fons Adriaensen wrote:
> On Sun, Aug 10, 2014 at 07:11:24PM +0200, Robin Gareus wrote:
> > It's not that easy.
> > Record enable is an application state not a position in time.
> > Rec-arm needs to allocate buffers, prepare files on disk etc etc.
> > It's not realtime-safe.
> 
> That is a weak excuse, and it hides the real reason. Which is
> that Jack transport does not require apps using it to remain
> ready to run while stopped, nor provides any means for an app
> to report 'not ready' until it's too late.

Mm, do you know about the 'slow-sync' Jack callback function?
Or do you propose something slightly different?
As in, able to report readiness anytime all the time even in stop mode?

The 'slow-sync' Jack callback function is a great feature for
 holding up the transport until all the apps report they are 
 'ready to roll'.

But, the callback is not polled until a transport start is initiated,
 whereupon the transport enters a special state JackTransportStarting
 and doesn't roll until all the apps agree, or a timeout value has expired.

We already use the callback to hold off Jack Transport until we have updated
 our wave playback caches and so on - when everything is ready to roll.

I reckon this callback will play a role in my efforts to add automatic + manual 
 latency compensation to MusE:
'Live' stream sources such as Jack inputs, and routing paths which have 
 plugin latencies, and so on, can be aligned simply by adding artificial delay 
 (that's extra latency, but unavoidable) to the various paths so that 
 everything aligns.
But there is one stream source which has a trick up its sleeve:
Playback sources. As in wave file playback (MusE Wave Track for example).
These sources can be queued up ahead of time, and the only way I see
 to do that is to use the 'slow-sync' Jack callback.
I can let the audio play for a moment while I hold up the Jack Transport
 and then let it go.

There is one situation that is tough: when an external HW midi device
 initiates the play via midi play command for example.
There is no way to tell it to hold off for a moment.
Well, there might be, if the midi interface is bi-directional (in + out).
Also, one could delay all input coming from the external HW midi device
 provided all its outputs are fed through the computer. But if for example 
 its audio outputs are fed right into a mixer, well, out of luck there...

I'm not sure that knowing all the time if the apps are ready to roll 
 even in stop mode would be helpful.
I mean, if the likely intention is to eventually go into play mode,
 then the 'slow-sync' Jack callback does what we need. Right?

> If you need to start 'on cue', which is a rather common thing
> in audio engineering, the present system just fails.
> 
> Sure, repositioning, creating new tracks or arming some of them
> for recording involves things that can't be done instantly and
> that are not RT safe. But a few seconds after a well-designed
> app is last repositioned or reconfigured it should be ready to
> start or go into recording mode instantly. And to make this
> useful at all the app should be able to report its readyness
> to a shared transport control so that 'one or more not ready'
> can be shown to the user somehow (typically done by flashing
> the START button).
> 
> All that is required is
> 
> 1. split the 'stopped' state in two: ready or not ready to
>    run as configured,
> 
> 2. require all apps, while stopped, to do whatever it takes
>    to get ready ASAP when reconfigured and report 'not ready'
>    meanwhile.

But... not ready for what? The app cannot know what the
 next transport intention is until the actual command
 comes down the line. For example a transport repositioning.
So the 'slow-sync' Jack callback seems to be the only way 
 to deal with this: Broadcast the actual command and wait until
 all the apps are ready to roll.

Cheers.
Tim.

> 
> I've proposed this a number of times over the last years, it
> was ignored each time. (1) is easy enough to implement, (2)
> is for application authors, not for the Jack team.