13 Aug
2015
13 Aug
'15
9:11 a.m.
----------------------------------------------------------------------
Message: 1
Date: Sat, 8 Aug 2015 16:48:45 +0000
From: Fons Adriaensen <fons(a)linuxaudio.org>
To: Linux Audio Developers <linux-audio-dev(a)lists.linuxaudio.org>
Subject: [LAD] Strange Jack1 problem
Message-ID: <20150808164845.GA7139(a)linuxaudio.org>
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
13 Aug
13 Aug
11:22 a.m.
New subject: Strange Jack1 problem
On 13 Aug 2015, at 08:10, Stéphane Letz
<letz(a)grame.fr> wrote:
I am surprised also JACK1 does no do topological sort which obviously is the needed
way...
Jack1 was always trying to do a topological sort, but it turns out the algorithm chosen
doesn’t always achieve one. This is a bug not a mis-feature: The surprise is that it took
well over a decade for anyone to spot it.
Simon
10:50 p.m.
New subject: Strange Jack1 problem
On Thu, Aug 13, 2015 at 10:21:58AM +0100, Simon Jenkins wrote:
That's a matter of opinion :-) A typo, forgetting to cover some
corner case, being off by 1 in a loop etc. etc. I'd call bugs.
Using the wrong algorithm is in a different class.
It also means that this was never seriously tested.
On 13 Aug 2015, at 08:10, Stéphane Letz
<letz(a)grame.fr> wrote:
I am surprised also JACK1 does no do topological sort which obviously is the needed
way...
Jack1 was always trying to do a topological sort, but it turns out
the algorithm chosen doesn’t always achieve one. This is a bug not
a mis-feature: The surprise is that it took well over a decade for
anyone to spot it.
Partly because in many cases you wouldn't notice a period
delay, or even several periods. It makes nonsense of any
latency compensation schemes etc. of course.
And I can assure you that it's not very rewarding to chase
a suspected bug in your own software for days on end because
you happen to be the type of fool who *does* do some testing
before releasing anything, only to discover that it's not
your 'bug' at all.
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)
11:43 p.m.
New subject: Strange Jack1 problem
On Thu, Aug 13, 2015 at 4:50 PM, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
I don't agree that this is why it wasn't noticed.
But tather than tilting at windmills, seeking to assign blame, and/or
complaining about already acknowledged ridiculousness of the
situation, we figure out how to fix it?
I have essentially no time right now to work on Jack1 myself, and that
won't change for at least a couple of months. There's already a
backed-up/delayed release that I haven't been able to get to.
On Thu, Aug 13, 2015 at 10:21:58AM +0100, Simon
Jenkins wrote:
The surprise
is that it took well over a decade for anyone to spot it.
Partly because in many cases you wouldn't notice a period
delay, or even several periods. It makes nonsense of any
latency compensation schemes etc. of course.
14 Aug
14 Aug
12:14 a.m.
New subject: Strange Jack1 problem
On Thu, Aug 13, 2015 at 05:43:51PM -0400, Paul Davis wrote:
On Thu, Aug 13, 2015 at 4:50 PM, Fons Adriaensen
<fons(a)linuxaudio.org> wrote:
I don't agree that this is why it wasn't noticed.
Then, why ?
The first reason, IMHO, is that it wasn't tested.
I'm pretty sure that if you throw say 100 *random* client/connection
configurations at it (rather than just the obvious ones), it will
fail in at a least 10 cases. And even one would be enough. This is
how you test any algorithm that isn't 'obviously correct'. And even
those that appear to be.
On Thu, Aug 13, 2015 at 10:21:58AM +0100, Simon
Jenkins wrote:
The
surprise is that it took well over a decade for anyone to spot it.
Partly because in many cases you wouldn't notice a period
delay, or even several periods. It makes nonsense of any
latency compensation schemes etc. of course. But tather than tilting at windmills, seeking to
assign blame, and/or
complaining about already acknowledged ridiculousness of the
situation, we figure out how to fix it?
I have essentially no time right now to work on Jack1 myself, and that
won't change for at least a couple of months. There's already a
backed-up/delayed release that I haven't been able to get to.
I don't have much time either. Could work on it while on holiday
in Greece in two weeks. But not very motivated to do so. Why not ?
Take my latest patch which reorganised some of the code that
maintains various timers (frame time and the DLL). It was the
result of several days of work, writing and testing. To my big
surprise, when investigating the latest issues, I found it was
actually integrated. But when I sent it to you more than a year
ago, it could as well have been sent to /dev/null. Not even a
single line reply.
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)
12:25 a.m.
New subject: Strange Jack1 problem
On Thu, Aug 13, 2015 at 6:14 PM, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
On Thu, Aug 13, 2015 at 05:43:51PM -0400, Paul Davis
wrote:
what you apparently mean to say, then, is that if someone had done
*random* testing on it, it would have been discovered. and that's
true. but *random* testing is a distinct methodology/process, and
you're right, nobody ever generated a test harness for that. the
testing that was done - it passed. But that's because, as was
indicated before, the tests were covering what was anticipated to be
real life scenarios. It wasn't enough.
On Thu, Aug 13, 2015 at 4:50 PM, Fons Adriaensen
<fons(a)linuxaudio.org> wrote:
I don't agree that this is why it wasn't noticed.
Then, why ?
The first reason, IMHO, is that it wasn't tested.
I'm pretty sure that if you throw say 100 *random* client/connection
configurations at it On Thu, Aug 13, 2015 at 10:21:58AM +0100, Simon
Jenkins wrote:
The
surprise is that it took well over a decade for anyone to spot it.
Partly because in many cases you wouldn't notice a period
delay, or even several periods. It makes nonsense of any
latency compensation schemes etc. of course. I don't have much time either. Could work on it
while on holiday
in Greece in two weeks. But not very motivated to do so. Why not ?
Take my latest patch which reorganised some of the code that
maintains various timers (frame time and the DLL). It was the
result of several days of work, writing and testing. To my big
surprise, when investigating the latest issues, I found it was
actually integrated. But when I sent it to you more than a year
ago, it could as well have been sent to /dev/null. Not even a
single line reply.
Sorry for the lack of response. I work 12-15 hours a day on open
source projects with communication flying in every direction. I don't
always do the best job of communication. I also tend to assume that
people who work on JACK in any way are on the commit mailing list.
You continually insinuate that I do a poor job of managing jack1, and
there's some truth to that. I'm entirely happy to turn it over to you
if you want to handle the pull requests, emails, releases and the rest
of the stuff that goes with it.
15 Aug
15 Aug
5:06 p.m.
New subject: Strange Jack1 problem
On Thu, Aug 13, 2015 at 06:25:04PM -0400, Paul Davis wrote:
You continually insinuate that I do a poor job of
managing jack1, and
there's some truth to that. I'm entirely happy to turn it over to you
if you want to handle the pull requests, emails, releases and the rest
of the stuff that goes with it.
No, but I am willing to tackle the current issue provided that
the solution doesn't end up in some black hole.
The solution I have in mind does not use DFS but is based on the
'forward activation' model as in Jack2 (and which is implicitly
used to control the current sorting as well).
Ideally it would not modify the engine->clients list at all but
maintain its own data. But apparently many other parts of the
system depend of having the actual 'sorted' list, so at least
for now the algorithm will use this list and keep it in order.
The part that actually computes the sequence of clients would run
only when the dependencies change (currently it's done after each
connection change):
- client added or removed,
- first connection between two clients is made,
- last connection between two clients is removed.
The complexity of this algorithm is linear in the number of
clients and the number of depencies between them (multiple
connections count as a single dependency). It runs once over
the list of clients, and for each one, once over the list of
other clients which depend on output from the current one.
There is no recursion in this part.
That means it *could* also be run in the actual cycle, i.e.
in the context of each client after its process() has run,
provided the required data is available there. In that case
it would also automatically run clients in parallel if the
dependencies allow it. Could be an interesting option for
the future, but it requires a lot more work. Also because
the explicitly sorted list (which would not be needed any
more) is used in so many other places.
'Delayed' connections (those that create a cycle) can be
reverted to normal ones as soon as possible (the current
implementation does this only when the entire graph has
becomes cycle-free). This does not require any additional
data. In particular it does not require access to the
actual connection lists, apart for updating the marker
that is currently there. So if that is not used anywhere
else (not sure) it can be removed.
Just let me know if you're interested.
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)
16 Aug
16 Aug
7:13 p.m.
New subject: Strange Jack1 problem
On Sat, Aug 15, 2015 at 03:06:23PM +0000, Fons Adriaensen wrote:
No, but I am willing to tackle the current issue
provided that
the solution doesn't end up in some black hole.
Just implemented it anyway :-)
Seems to work well, needs more testing.
Then if anybody is interested, drop me a line.
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)
13 Aug
13 Aug
10:33 p.m.
New subject: Strange Jack1 problem
On Thu, Aug 13, 2015 at 09:10:38AM +0200, Stéphane Letz wrote:
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.
I'm well aware of that. It's also the only solution if you have
concurrent threads and the running time of each client's process
can't be assumed to be constant and known.
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)
3384
days inactive
3387
days old
linux-audio-dev@lists.linuxaudio.org
8 comments
4 participants
participants (4)
-
Fons Adriaensen -
Paul Davis -
Simon Jenkins -
Stéphane Letz