[linux-audio-dev] Project: modular synth editor

Steve Harris S.W.Harris at ecs.soton.ac.uk
Tue Jan 20 10:56:40 UTC 2004


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



More information about the Linux-audio-dev mailing list