On Mon, Jan 19, 2004 at 08:56:52PM +0000, Simon Jenkins wrote:One or two cycles, depending on whether the client containing A and B guesses
Worse:
JACK -> A -> JACK -> C -> JACK -> B -> JACK
Where C is in a separate client.
Now...
+-------+
| | +---|<- C <-|<--+
| | | | | +-------+ |
| |
| +-------+ |
JACK ------>|-> A ->|---+
| | |
+-->|-> B ->|----------> JACK
+-------+
Oh dear... C needs to be called between A and B, but even if JACK and the
two clients know that A->C->B is the correct order (which none of them do)
it can't be achieved because A and B must be processed in a single callback.
This will 'work', AFAICS, but with one cycle delay.
correctly that A comes before B in the overall graph. (It doesn't know).
Once you start routing data out of a client and back into it, neither JACK nor theThis sets me thinking about using JACK for insertion points in a mixer. This will always introduce extra delays...
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.
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.
Simon Jenkins (Bristol, UK)