[Jack-Devel] issues with latency management with "complex" clients

as most of you know, torben implemented support for the expanded
*correct* version of JACK"s latency management (as shown in
http://ardour.org/files/jack-latency.png). i use the term "correct"
here simply to mean that the latency numbers that can be seen within
the graph (by JACK or by clients) reflect *all* signal flow within the
graph, and not just the flow involving explicit port connections known
to JACK.

as i've cooked up the ardour support for this, i've encountered an
issue which i think is either incredibly deep, or incredibly
ignorable, and want to know what other JACK developers think.

JACK tends to assume that as long as port connections stay the same,
the graph is essentially static and unchanging. But the presence of
applications that can deliver audio from other ports OR from internal
sources (e.g. synthesis or disk playback) complicates this quite a
bit.

Consider Ardour. When  a track in Ardour is in playback mode, its
effectively functioning like a synthesizer (or just a simple file
playback client). The connections to and data arriving at the track's
input ports are completely irrelevant. In playback mode, the track
effectively has a set of output ports that should be marked
JackPortIsTerminal to indicate that the audio data available there
does not originate anywhere else in the JACK graph.

But now switch the track into recording mode, with monitoring enabled.
What appears at the track's output ports is now totally dependent on
the connections to the track's input ports. The track is no longer
functioning as a synth or file playback engine, but instead is more
like a passthru FX unit. Its output ports are definitely not
"Terminal" - all data presented at the outputs comes from the inputs.

As the track is switched between these two modes, the answers to the
two questions regarding latency change. These questions are (from the
diagram referenced above):

    * how long has it been since the data read by a client from an
input port arrived at the edge of the graph? ("capture" latency)
    * how long will it be before data written by a client to an output
port will arrive at the edge of the graph? ("playback" latency)

Client's like Ardour effectively change where the "edge" of the graph
is - in playback mode, the track itself is the edge of the graph where
data originates. When recording+monitoring, the edge of the graph
moves back to the ultimate source of whatever the track is recording.
As a result, the answer to the capture latency question depends on
which mode the track is in ... but also note that the upstream
playback could be considered as changing too. If Ardour is recording,
say, Specimen, the playback latency for Specimen's data may depend on
which mode the track is in also. If the track is in playback mode,
then there's no audio path for Specimen's data through Ardour at all.
If its recording+monitoring, then there is a path through the track
that may be affected by plugin latencies.

So the question is: should anything be done about this? Should ardour
force a recompute of the latencies when a track changes modes? This is
quite expensive and definitely non-RT in jack1; its doable with
tschak. jack2 does not have an implementation of this latency API yet.
Could we just redefine the latency specifications into something that
is still useful, but avoids this issue? Or something else?

--p

1297866925.19668_0.ltw:2,a <AANLkTi=GVvaugNuBZAhdph7Dg9u-OUR5OwW7h9kkLURL at mail dot gmail dot com>