[LAD] Strange Jack1 problem

Fons Adriaensen fons at linuxaudio.org
Sat Aug 15 16:56:14 UTC 2015


On Sat, Aug 15, 2015 at 05:14:12PM +0100, Simon SD1 wrote:
> 
> > On 15 Aug 2015, at 16:06, Fons Adriaensen <fons at 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)



More information about the Linux-audio-dev mailing list