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

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Project: modular synth editor
From: Simon Jenkins (sjenkins_AT_blueyonder.co.uk)
Date: Mon Jan 19 2004 - 22:56:52 EET


Fons Adriaensen wrote:

>On Mon, Jan 19, 2004 at 02:56:52AM +0100, Fons Adriaensen wrote:
>
>
>>The point is IMHO that JACK is great for making audio connections between
>>independent Linux processes - that what it's designed for, and what it does
>>extremely well (BTW congrats to Paul and the whole JACK team for the Open
>>Source Award). But using JACK for internal connections is pure overkill,
>>and I'm not even sure it will work as you expect.
>>
>
>Sorry to follow upp on my own ramblings, but I'm getting more and more
>convinced that using JACK for internal connections in a modular synth will
>not work as expected.
>
>For example, take the patch
>
>JACK -> A -> JACK -> B -> JACK
>
>where A and B are two processing modules.
>
>If A and B are inside the same JACK client, what will happen ?
>Will jack use a single buffer for A-out and B-in (this is what you'd
>expect in a modular synth), or will it copy the previous A-out to B-in
>before calling your process callback, thereby introducing one cycle
>delay ?
>
If A and B are modules *inside the same JACK client* (rather than, for
instance, two JACK clients instantiated by the same application) then
the situation is something like this:

        +---------------+
        | +-------+ |
JACK ------>|-> A ->|---+
        | | |
        +-->|-> B ->|----------> JACK
            +-------+

Note that the client contains connectivity that is invisible to JACK: As
far as
JACK can tell the client is a black box with 2 inputs and 2 outputs,
requiring
a single process callback (which is all that a client is going to get in
any case).

Will a delay be introduced? Not so long as the client processes A before B
in its callback. But *neither JACK nor the client* posesses the information
to determine that this is the correct order!

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.

Simon Jenkins
(Bristol, UK)


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Mon Jan 19 2004 - 21:54:29 EET