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

Simon Jenkins sjenkins at blueyonder.co.uk
Tue Jan 20 21:43:45 UTC 2004


Steve Harris wrote:

>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,
>
Actually, yes it is always 1 ( the totally incorrect BCA is unachievable
for the same reason that the totally correct ACB is: Because C can never
execute in between A and B). My mistake, but I'm still describing a real
problem:

> theres no "guessing" what the order is, the graph is
>sorted by the jack demon.
>
There *is* guessing.

The trouble comes when clients have non-trivial internal graphs of
their own. JACK can't see the internal graphs of clients. It assumes
that all outputs of a client are dependent on all inputs of that client,
so any attempt to route a signal out of a client and then back into it
looks like feedback to JACK, even when there isn't any real feedback
going on.

And the client can't see the external JACK graph either. If a client's
internal graph consists of two disjoint subgraphs...

:      ########################
:      #                      #
:      >in1 --> MOD A --> out1>
:      #                      #
:      >in2 --> MOD B --> out2>
:      #                      #
:      ########################

...then the client doesn't know which subgraph to process first. If the
user has connected out1 directly to in2 then it should do the MOD A
chain first, but if the user has connected out2 directly to in1 then it
should do the MOD B chain first. If the client guesses wrong then
an unnecessary delay is introduced.

If the user has connected out2 *indirectly* back to in1 then the MOD B
chain should execute first, followed by some other stuff in some other
clients, followed by the MOD A chain. But even if JACK and the client
cooperated to find this out (neither could work it out for themselves) it
would require per-input process callbacks from JACK - rather than
per-client callbacks - to achieve it.

I actually started coding a mod to JACK last year to deal with this
stuff, but then got suck(er)ed down a sidetrack from which I haven't
so far returned.

Simon Jenkins
(Bristol, UK)





More information about the Linux-audio-dev mailing list