12 Aug
2014
12 Aug
'14
2:01 a.m.
On August 11, 2014 10:05:59 AM Fons Adriaensen wrote:
On Sun, Aug 10, 2014 at 07:11:24PM +0200, Robin Gareus
wrote:
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?
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. 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.