Re: [Jack-Devel] The Situation(s) With JACK

PrevNext  Index
DateThu, 15 Dec 2011 11:07:02 +0100
From Stéphane Letz <[hidden] at grame dot fr>
ToJACK <[hidden] at lists dot jackaudio dot org>
In-Reply-ToPatrick Shirkey Re: [Jack-Devel] The Situation(s) With JACK
Follow-UpChris Caudle Re: [Jack-Devel] The Situation(s) With JACK
Le 15 déc. 2011 à 04:23, Patrick Shirkey a écrit :

> 
>> On Wed, December 14, 2011 7:55 am, Paul Davis wrote:
>>> i don't think that *anyone* believes that the C code
>>> base of JACK1 is an appropriate thing to keep developing.
>>> certainly I do not.
>> 
>> The referenced message was probably the most concise I have seen so far
>> regarding JACK1.
>> 
>> Going from the other direction, what is lost by just saying that Grame is
>> now the maintainer of JACK, and even though JACK1 developers do not
>> particularly like working on the JACK2 code, they just punt and let
>> Stephane et al. implement any future changes.
>> 
>> Have there been any API changes except for the latency changes in the last
>> couple of years?  Are any additional changes currently planned?  Is there
>> any reason that for future changes the implementation of the changes could
>> not just be left to the JACK2 developers, while the (previous) JACK1
>> developers just concentrate on application development?
>> 
> 
> 
> It's unnecessary to take that route.
> 
> Paul has identified significant issues on his part with the codebase for
> jack2. It affects others too. Stephane has said he agrees there is room
> for adjusting the codebase of jack2 to make it easier for people to work
> with who do have problems with the current implementation.
> 
> Hence we just have to identify the areas that need to be fixed and make
> them easier for everyone to work with. In the process we should end up
> with a more powerful system.
> 
> As long as someone has time to commit to the refactoring process it's a
> win win. We end up with a single codebase that everyone is happy to work
> which makes it easier for packaging and we all can move forward.
> 

I'm sure we can find a satisfactory solution for everyone that as the same time reuse part of the code (like OS specific backend/bridge) and redesign some part (or all) of the "core JACK", using more modern design/library (like boost....): 

-using boost would probably allow to abstract : multi-OS server/client communications channels, synchronization primitives, threads (although we have to precisely look at real-time thread support...), shared memory manager... This would allow to remove a lot of code that does exactly that in JACK2 and concentrate better on "core JACK" which is basically: client/server communications, graph management and scheduling, interactions with backends...etc...

I plan to release 1.9.8 quite soon (since it has a lot of new stuff and some important bug fixes and improvements). Then make concrete proposal in this direction. 

Stéphane 
PrevNext  Index

1323943618.19234_0.ltw:2,a <3C525012-BD3E-415B-B5BC-19297FEB1A1C at grame dot fr>