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

PrevNext  Index
DateMon, 19 Apr 2010 08:06:59 +0200
From Stéphane Letz <[hidden] at grame dot fr>
Totorbenh <[hidden] at gmx dot de>
CcJack devel list <[hidden] at lists dot jackaudio dot org>, [hidden] at lists dot linuxaudio dot org
In-Reply-Totorbenh Re: [LAD] [Jack-Devel] distros migrating to JACK2?
>> 
>> 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.

Because 3 different platform dependant communication scheme are supported : Mig generated RPC on OSX, sockets for Linux/Solaris, pipes on WIndows. And a new API has to be implemented on server and library side, thus as several places yes.

Since jack2 OSX version was developed first, Mig generated RPC was tested at that time. It could probably be replaced by Posix socket code, but last time I tried if was failing (I guess they are still some subtle differences between OSX and others Posix OS concerning sockets.) 


> 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,

Like what?


> 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 ?)

Because on OSX the "event processing loop" is handled in the Mig generated RPC code , so the "event processing loop" moves in the "platform specific communication channels". 

If OSX specific stuff is removed, then the "event processing loop"  may go in a more generic part the code yes.

> 
> 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.

A Linux specific version ? (so would be simpler yes) or a multi-platform version?

> for me this has the benefit of not using CamelCase. which will never get
> removed from jack2 (why should it? stephane likes it)

So naming convention (class, class fields...)  yes?
> 
> 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
> alternative.
> 

I don't see (yet) any of the proposed arguments as "fundamental" critic of the jack2 design. Some improvements are certainly possible, like trying to remove this OSX specific server//client communication code, and we could agree on that. I don't think starting a new c++ implementation will improve the situation. If a Linux specific version only is developed, then we move a step back yes?. But OTOH nobody is never forced to do anything in OSS. 

Stéphane
PrevNext  Index

1271657269.10552_0.ltw:2,a <EE779AAA-0873-4B8C-9EC3-EDC79D9D4629 at grame dot fr>