Subject: Re: [linux-audio-dev] Project: modular synth editor
From: Steve Harris (S.W.Harris_AT_ecs.soton.ac.uk)
Date: Tue Jan 20 2004 - 12:56:40 EET
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
This archive was generated by hypermail 2b28 : Tue Jan 20 2004 - 12:59:26 EET