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

[Simon Jenkins]

Fons Adriaensen wrote:

>On Mon, Jan 19, 2004 at 08:56:52PM +0000, Simon Jenkins wrote:
>
>  
>
>>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.
>
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).

> 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.

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)