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
