[LAD] [Jack-Devel] distros migrating to JACK2?

torbenh torbenh at gmx.de
Sun Apr 18 22:03:30 UTC 2010

On Sun, Apr 18, 2010 at 10:21:06PM +0200, rosea.grammostola wrote:
> On Sun, 2010-04-18 at 08:31 -0400, Paul Davis wrote:
> > On Sun, Apr 18, 2010 at 5:16 AM, rosea.grammostola
> > <rosea.grammostola at gmail.com> wrote:
> > > It's pretty odd that you guys didn't discuss this clearly with each
> > > other. It seems that people have an opinion about something, but only
> > > share this with people who have the same opinion and not with the one
> > > who himself or his code is subject of 'critique'. This is bad
> > > communication and bad team management.
> > 
> > oh god. you clearly don't understand ANYTHING about how open source
> > development works.
> > 
> > there was constant discussion about all of this. But Stephane doesn't
> > own JACK, I don't own JACK, Torben doesn't own JACK, Jack O'Quinn
> > doesn't own JACK. When someone works on their own implementation of
> > JACK, they are free to make their own decisions about how things are
> > done. Maybe their ideas will be better (or worse, or about the same)
> > as any existing implementation, and because of this, its important to
> > allow them to take shape as they see fit. Clearly, providing useful
> > feedback and ideas is great, but there's no reason for any committees
> > or meetings to decide how a different implementation is going to work.
> > 
> > In this particular case, Jack2 started out (as Stephane has described)
> > as a sort of experiment - how would SMP support work, could we do
> > click-free graph changes, would a C++ implementation be easier to
> > manage, etc. etc. In that context, its not appropriate for anyone
> > who's not actually working on it to be trying to make decisions about
> > internal design. Lots of people, including myself, had input into the
> > design and evolution of Jack2. Pretending otherwise is ridiculous.
> > 
> > Jack1, Jack2 (and even the not-quite-born tschak) all implement 99.83%
> > of the same API. Beyond that, how they work internally is the business
> > of their implementors and maintainers. If someone has an opinion about
> > it, they are free to take it up with the implementors and maintainers.
> > If they feel strongly enough about it, and they don't feel that the
> > implementors/maintainers are doing things in the right way, they can
> > fork or reimplement (this clearly doesn't happen much).
> This could all be true, but that's not the point I was talking about.
> JACK2 was planned as successor of JACK1. But at some point that changed,
> that's all ok, not the point here. But isn't it odd that this isn't
> clearly communicated with the JACK2 maintainer, why this is happened?
> That was raising questions here about the communication within the
> (highly appreciated) JACK project. 

its sort of my fault. i dont feel comfortable with the jack2 codebase.
this partly has to do with the style used. 
the important thing however is the class hirarchy.

i find it unacceptable that i need to add a method to 5 classes to
implement some new api function for example.
i end up writing a lot of boilerplate code i find useless, and 
i really hate to write useless code.

many of the other design decisions dont make sense to me, and i am
having a pretty hard time finding the relevant code fragments.
(who would search for the servers event processing loop in the platform
specific Communication channels ?)

this makes hacking jack2 a rather unpleasant experience for me.
since nobody pays me to work on jack and i am doing this for fun.
i minimize hacking jack2.

yet since nobody will do the jack2 session patch i am forced again to
work on jack2.

i wrote tschack because i wanted to try out a different approach to the
functionality in jack2. and to understand how a parallel jack works.
now some people who had bad experience with jack2 tried it, and it works
for them. 
so there is no reason to hide tschack. 

i dont see a reason to try to get stephane to reconsider his design
decisions. it were his decisions, and he seems to be happy with them.
my way is to start from scratch with a new c++ implementation.
for me this has the benefit of not using CamelCase. which will never get
removed from jack2 (why should it? stephane likes it)

regarding distros move to jack2 i think its the right thing.
i just made sure, that it will be possible to install an alternative
jack implementation. 
iE people had a pretty hard time installing jack2 on debian. 
if they had just moved to jack2 without making libjack a virtual
package, people would have problems instlling jack1 or tschack.
now the packagers dont really want to package N versions of jack, since
they would need to test all combinations of apps and jacks.

but as long as sombody is able to provide jack1 and tschack .debs it
will be fine.
packagers are happy, and other people are able to install some

> quote=Stephane
> > I must say that I still don't have a clear understanding of why this
> > happened. I still don't understand the sentence "Like Torben, there
> > are some design decisions there that I have questions about." and I
> > think explaining it in more details would really help. 
> Regards,
> \r
> > 
> > > It would be good if an '(mini) JACK Conference' will be organized, where
> > > JACK developers can speak each other face to face, code to code. And
> > > share future vision, coding vision etc. IRC and mailinglists are great,
> > > but not always the good method for communication.
> > 
> > Traditionally, this would be done at the Linux Audio Conference, which
> > I will, alas, be unable to attend this year. That doesn't stop other
> > people from meeting on these issues, but my impression is that we have
> > all become somewhat tired of struggling with the situation and instead
> > have been trying to find ways to allow the status quo to continue, but
> > better.
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev at lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev

torben Hohn

More information about the Linux-audio-dev mailing list