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

PrevNext  Index
DateWed, 16 Feb 2011 12:18:01 -0600
From Chris Caudle <[hidden] at chriscaudle dot org>
To[hidden] at lists dot jackaudio dot org
Follow-Uptorbenh Re: [Jack-Devel] issues with latency management with "complex" clients
On Wed, February 16, 2011 9:30 am, Paul wrote:
> JACK tends to assume that as long as port connections stay the
> same, the graph is essentially static and unchanging. ...
> As the track is switched between these two modes, the answers
> to the two questions regarding latency change.
...
> Client's like Ardour effectively change where the "edge" of the graph is


Seems like changing modes is actually a special case of graph change,
where the graph changes but the connected ports do not change.

Would it be reasonable for applications to ignore it by default, but tell
jack that the graph changed in cases where the app cares?  In the given
example, Ardour would decide whether it mattered or not, and if it did
call to jack to say "the graph changed, recalculate."  Other apps would
not care, so they would never make the call.

When you say expensive, what kind of time are you talking about?  Going
from playback to record takes a couple of clicks, so if you are talking
seconds it would annoy a user, if you are talking tenths of a second it
might not be noticeable.

Is part of the concern that it would cause clicks on jack 1, or that for
large configurations the recalculation time scales with the graph size, so
it might not bother me with a handful of tracks, but it would definitely
bother someone with lots of tracks and dozens of soft synths connected?

-- 
Chris Caudle
PrevNext  Index

1297880312.16355_0.ltw:2,a <79219ce10b5bf7e69c65d2d191516840.squirrel at email dot powweb dot com>