----- Forwarded message from Fons Adriaensen <fons(a)linuxaudio.org> -----
Date: Mon, 10 Aug 2015 19:46:15 +0000
From: Fons Adriaensen <fons(a)linuxaudio.org>
To: Paul Davis <paul(a)linuxaudiosystems.com>
Some new evidence which may be useful. It seems the
problem occurs only if at least one client is running
before zita-*2* and jack_delay are started.
In the logfile added below, the lines between the '----'
are the ouput of some printf() added to jack_rechain_graph().
The name of each client is printed as the list is traversed,
(near to top of the main loop) and a '*' is printed when a
new chain is started.
fons@erc-linux1:~> /usr/bin/jackd -P70 -p1024 -u -dalsa -dhw:UA22,0 -r48000 -p256 -n2
jackd 0.124.1
Copyright 2001-2009 Paul Davis, Stephane Letz, Jack O'Quinn, Torben Hohn and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK compiled with System V SHM support.
loading driver ..
apparent rate = 48000
creating alsa driver ... hw:UA22,0|hw:UA22,0|256|2|48000|0|0|nomon|swmeter|-|32bit
configuring for 48000Hz, period = 256 frames (5.3 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 24bit little-endian
ALSA: use 2 periods for capture
ALSA: final selected sample format for playback: 24bit little-endian
ALSA: use 2 periods for playback
------------------------------
------------------------------
# 1. Start Qjackctl
------------------------------
------------------------------
# 2. Start japa
------------------------------
japa
*
------------------------------
# 3. Start zita-j2n
------------------------------
japa
*
zita-j2n
------------------------------
# 4. Start zita-n2j
------------------------------
zita-j2n
*
japa
zita-n2j
------------------------------
# 5. Start jack_delay
------------------------------
zita-n2j
*
japa
zita-j2n
jack_delay
------------------------------
# 6. Connect zita-n2j -> jack_delay
------------------------------
jack_delay
*
zita-j2n
japa
zita-n2j
------------------------------
# This looks already wrong... jack_delay
# can't be first.
# 7. Connect jack_delay -> zita-j2n
------------------------------
zita-n2j
*
japa
jack_delay
zita-j2n
------------------------------
# Correct delay is measured.
# 8. Connect system:capture_1 -> japa_in_1
------------------------------
jack_delay
*
zita-j2n
japa
zita-n2j
------------------------------
# The order of execution is wrong and
# measured delay increases by one period.
# 9. Connect system:capture_2 -> japa_in_2
------------------------------
zita-n2j
*
japa
jack_delay
zita-j2n
------------------------------
# Correct delay measured again.
# 10. Disconnect system:capture_1
------------------------------
jack_delay
*
zita-j2n
japa
zita-n2j
------------------------------
# Wrong again.
# 11. Disconnect system:capture_2
# ------------------------------
zita-n2j
*
japa
jack_delay
zita-j2n
# ------------------------------
# OK
etc. etc.
--
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)
----- End forwarded message -----
--
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)
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)
