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

PrevNext  Index
DateMon, 12 Dec 2011 15:30:08 -0500
From Paul Davis <[hidden] at linuxaudiosystems dot com>
ToStéphane Letz <[hidden] at grame dot fr>
CcJACK <[hidden] at lists dot jackaudio dot org>
In-Reply-ToStéphane Letz Re: [Jack-Devel] The Situation(s) With JACK
Follow-UpStéphane Letz Re: [Jack-Devel] The Situation(s) With JACK
Follow-UpTobias Hoffmann Re: [Jack-Devel] The Situation(s) With JACK
On Mon, Dec 12, 2011 at 11:15 AM, Stéphane Letz <[hidden]> wrote:

> You are basically describing the current state of JACK2 *minus* some parts....
>
> Do you really want to start a JACK3 project with a new implementation ??

Not really.

But I also don't expect you to agree with the reasons why neither
Torben or myself were willing to "migrate" to Jack2. The fact that
Jack2 is written in C++ doesn't alter the fact that things that ought
to be simple to add or extend there simply are not. Both of us have
gone to add things to Jack2 and found ourselves bewildered by the
class architecture. This is expected in the much more spaghetti-like C
code of Jack1, which lacks on ability to inherit functionality across
classes. But part of the reason to endorse a C++ implementation was to
make things much more modular, and although Jack2 superficially looks
that way, in practice in seems not to be.

If you want to commit to ensuring that Jack2 will provide all the
functionality listed, and whatever else the user base comes up with,
then fine, those of us who have issues with the codebase in Jack2 can
just walk away and leave it with you (to some extent we already are,
because of your support for and work on the OS X and Windows ports).
But I think that (a) you probably don't want to make that committment
and (b) the JACK community would be better served by an implementation
on which more people were willing to work. As it stands, we're never
likely to see the work Torben has put into alsa_in/out appearing in a
more integrated form as the Jack2-style "adapters". This is just one
example.

> I don't know what to say more...

Apparently, these items from my list escaped your attention:

   >    full memory locking when platform supports it
   >    memory use for ports proportional to number of ports
   >    no fixed limit on number of ports
   >    multiple device support handled by server (from Jack2, but
with  the quality of alsa_in/alsa_out)
   >    realtime device switching (without stopping/restarting server)
   >  single header file tree, for use by jack1, jack2 and anything else
   >  single tool dir tree, for use by jack1, jack2 and anything else
   >  **proposal** use Boost widely to accelerate development and
leverage existing work.

You're also ignoring the need to have a single netjack streaming
protocol, moving D-Bus interaction into a separate component so that
it is on the same level as any other protocol.

These are not small issues, though some of them are not "hard coding" problems.

Do you have some alternate proposal for how to address the issues I
opened this thread with?
PrevNext  Index

1323721820.22669_0.ltw:2,a <CAFa_cKmUoydsfvzbvg=8ZrXY4O5hX_JFyJinmhtNe7veDSPJzg at mail dot gmail dot com>