Re: [LAD] Strange Jack1 problem

Although it pains me to say it, I think the simple fact is that none
of the people close enough to the code understood that we need to use
topological sort.

When we ran into problem inside Ardour in 2011, we came to realize
that toposort was the "standard" solution for this, but back in
2001-2004, none of the people who mattered with respect to this code
realized that is was (a) necessary (b) a well-known solution.

On Tue, Aug 11, 2015 at 6:48 PM, Simon Jenkins <sjenkins@steppity.com> wrote:
>
>>> I think the underlying sort mechanism was the same before I did
>>> that
>>
>> It seems to have been like that for as long as the the git history
>> goes back, which is to 2006.
>
> Fons,
>
> Turns out my patch was late 2004 but I’ve confirmed — quick look — that minus the feedback connection stuff it was doing the same before. (Just gotta add there was also a substantial explanatory comment right where I dropped mine).
>
> I note though that drivers were/are treated as a special case and forced to the front, and that historically the major use cases for Jack would have involved connections to a driver, likely the same driver, at some point. Not saying that fixes the problem but it may have helped disguise it for so long: It took your entirely free-floating n2j/j2n chain, plus other clients started and stopped at the right moment, before it did something noticeably wrong.
>
> Simon
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Wed Aug 12 04:15:01 2015