[LAD] Strange Jack1 problem

Fons Adriaensen fons at linuxaudio.org
Sat Aug 8 16:48:45 UTC 2015


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)



More information about the Linux-audio-dev mailing list