On Tue, Jan 20, 2004 at 01:55:54 +0000, Simon Jenkins wrote:
This will
'work', AFAICS, but with one cycle delay.
One or two cycles, depending on whether the client containing A and B
guesses
correctly that A comes before B in the overall graph. (It doesn't know).
No, its always 1, theres no "guessing" what the order is, the graph is
sorted by the jack demon.
This sets me
thinking
about using JACK for insertion points in a mixer. This will always
introduce
extra delays...
Once you start routing data out of a client and back into it, neither
JACK nor the
client know how to order their graphs. A mixer client could guess that
the pre-insert
sections of its signal paths precede the post-insert sections
(minimizing, but not
eliminating, the extra delays) but even this could be wrong: The user
might have
used JACK to "insert" one path through the mixer into another path
through the
mixer.
Feedback loops are the only time you get arbitrary extra latencies, jack
has to choose to break the loop somewhere, generally it doesnt really
matter where.
In the case of interconnecting modular synths via JACK
it gets even worse
because the internal graphs of the synths will be changeable. In the
extreme this
could cause glitches if an adjustment to the routing within a synth app
caused
the number of introduced delay cycles to change.
In the general case you will get glitches on graph connections anyway -
jack has to erform some non-RT operations.
- Steve