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 A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)