On Sat, Aug 15, 2015 at 05:14:12PM +0100, Simon SD1 wrote:
On 15 Aug 2015, at 16:06, Fons Adriaensen
<fons(a)linuxaudio.org> wrote:
'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).
The options discussed in 2004 were to revert those connections
when the entire graph became cycle-free, or never to revert them
so long as they existed.
Waiting for all cycles (if there were ever more than one) to be
broken seems IMHO no better than reverting ASAP. In both cases
the changes are probably not anticipated by the user. My personal
preference would be to never revert such connections.
The rationale for never reverting them was that a pair
of connected
clients would suddenly be running in a different order — and a buffer’s
worth of data between them would vanish
But that can happen anyway in Jack1 if a cycle is skipped.
The rationale for reverting them was lower latency,
and to prevent
pathological cases where a chain of clients could be running in entirely
the wrong order because of cycles that used to exist but don’t any more.
Seems rather unlikely. If such things are a real problem, then the clean
solution is to make things explicit to the user, but this requires a
change of the API: when a connection is made, you could have the options
- don't care (default), but return result,
- must be normal, fail if not possible,
- must be delayed, fail if not possible.
I've done this in a multithreaded single-process framework (for
things like softsynths, mixers, etc.) It allows to set up feedback
connections in a controlled way.
With the algorithm I have in mind, never reverting is the easiest,
doing so ASAP comes next, and reverting only if the result would
be completely cycle free would be the hardest.
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)