Subject: Re: [linux-audio-dev] Project: modular synth editor
From: Simon Jenkins (sjenkins_AT_blueyonder.co.uk)
Date: Tue Jan 20 2004 - 03:55:54 EET
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)
This archive was generated by hypermail 2b28 : Tue Jan 20 2004 - 02:56:50 EET