Re: [LAD] Strange Jack1 problem

>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 8 Aug 2015 16:48:45 +0000
> From: Fons Adriaensen <fons@email-addr-hidden>
> To: Linux Audio Developers <linux-audio-dev@email-addr-hidden>
> Subject: [LAD] Strange Jack1 problem
> Message-ID: <20150808164845.GA7139@email-addr-hidden>
> Content-Type: text/plain; charset=us-ascii
>
> Hello all,
>
> I've been testing some new features of zita-njbridge. The test
> setup was:
>
> zita-n2j -> jack_delay -> zita-j2n
>
> with the loop closed via the network. The purpose of the test was to
> verify the added latency. It produced the expected result - until I
> started another (unrelated) Jack app. Suddenly the delay increased
> by one period. Stopping the other app had no effect. Restarting it
> made the measured delay return to its original value. Then each
> time another app (no matter which one) was started or any ports
> were connected or disconnected, the delay switched been these two
> values.
>
> First I suspected some bug in zita-njbridge - it has some logic to
> detect skipped cycles etc. and handle them gracefully. But I found
> no error there, and the problem also occured when no cycles were
> skipped.
>
> The I let n2j write the jack usecs time at the start of its process()
> to shared memory, and j2n read it and print the difference with its
> own process() time. This confirmed what I suspected: when the delay
> increased, the order of execution of n2j and j2n was reversed.
>
> Note that as far as Jack is concerned there is no loop in the
> graph, and hence no ambiguity as to the correct order.
>
> So the conclusion seems that Jack1 is doing something unexpected
> each time the graph order is recalculated.
>
> This seems to depend on how many apps or ports are active before
> the test is started. When the test apps are the first ones all
> seems to be OK.
>
> I could not reproduce the problem with Jack2.
>
> Has anyone noticed similar things ?
>
> Ciao,
>
> --
> FA
>

I am surprised also JACK1 does no do topological sort which obviously is the needed way...

Note that JACK2 does not need to do topological sort of the client graph, since it's client activation system is based on a "data flow" model. Client "order" is found out with this "activation token" model that goes progressively from inputs to outputs during a given cycle. It means that for instance the following graph :

IN ==>A ==> OUT
IN ==> B ==> OUT

where A and B are connected to IN and OUT, and that would be topologically sorted to 2 correct activation sequences (either IN ==> A ==> B ==> OUT) (or IN ==> B ==> A ==> OUT) would be activated in parallel in JACK2, so A can possibly run before B, or the contrary, or both at the same time on 2 different cores….

Stéphane

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Thu Aug 13 12:15:02 2015