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

Hi!

In the example you provided, for each track, couldn't you, just define
one output port for playback mode and one for recording mode, and then
change connections depending on mode? Or would that be too expensive?
Latency computation would theoretically only have to be done once for
each of the two ports, wouldn't it?

Just my 2 cents...

Arne

On 16.02.2011 15:35, Paul Davis wrote:
> 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
> 
> Jack-Devel mailing list
> [hidden]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

1297869703.26027_0.ltw:2,a <4D5BEB71.8010800 at gmail dot com>