On Fri, Apr 16, 2010 at 3:36 PM, Adrian Knoth <adi@email-addr-hidden> wrote:
> It's debian-specific. I don't know the details, but the build system
> can't resolve dependencies on virtual shared libraries. Something like
> that.
That's pretty pathetic. But I guess there's not much to be done about that.
> Card reservation. That's what users are most whining about.
>
> I already proposed something like jackd -d pulseaudio, so the non-pro
> users can run their occational ardour session on top of PA without the
> need to ever shut it down.
Lennart and myself, had long discussions in Berlin last year, followed
by actual work from Nedko to implement what Lennart had suggested (or
something close to it). I'm not clear why distro packagers (and I'm
speaking generally here - you've been exemplary in getting debian
patches back to us) feel the need to ignore the design decisions of
PulseAudio and JACK's designers. The problems with interactions
between the two come from the fact that JACK is cross-platform and
that therefore these kinds of mechanisms need to be added carefully in
ways that don't cause issues for users on other platforms. This has
led to the PA/JACK "cooperation" not developing as fast or as deep as
we would like. One of the things that Lennart and I both agreed upon
VERY emphatically was that when a user starts up JACK, our conclusion
is that they *intend* for other audio routing to get out of the way,
and thus PA would go along with it. Adding a pulseaudio backend
totally inverts that assumption.
> I also provided a proof-of-concept implementation, I've shown a working
> ardour session on top of pulseaudio. Sure the latency is crap, but let's
> be honest? Who's connecting his el-cheapo laptop card to a pro setup?
> They buy themselves a Multiface, a FFADO-supported card or some other
> pro gear. ;)
if they are not connecting JACK to their el-cheapo laptop card, then
the issue doesn't arise, does it?
> Anyway, to have this documented: I came to #jack some weeks ago and
> asked whether it's right to move to jackd2 or not. Nobody cared to give
> an answer, yours was "That's a political question."
as it is. so lets tackle this head on and without reservations.
about 3 years ago, the JACK mini-summit in Berlin agreed that
stephane's implementation of jack would become the future of JACK. i
can't speak for everyone who was there, but for my part, there were a
several reasons for this decision:
* stephane's version already supported SMP
* stephane's version already had support for "click free graph changes"
* stephane's version was written in C++ and was more modular in
its internal design than jack1
* stephane had become the most active developer/maintainer of JACK
* stephane was likely to port his implementation to Windows (OK,
we didn't actually know this at the time, but its turned out to be of
some significance)
* there was a lot of discussion about the "JACK Control API" and
it seemed easier to imagine implementing this
in the context of stephane's implementation
Other's might have had some other reasons too, but I think those were mine.
What has happened since then is that the active JACK developer
community has shrunk down to about 3.25 people (Stephane, Torben Hohn,
myself and occasionally Nedko). This is hardly suprising given the
status of the project, but it does have some ramifications. And the
ramifications are that Torben, who has recently been the most active
for a while, feels uncomfortable working on the jack2 codebase and is
dissatisfied with some of the design decisions in Jack2. Because of
the very small size of the development community, this disagreement is
essentially one of personal style, and the two of them have basically
agreed to disagree while working to avoid doing anything to make the
current situation worse. When you have basically 2 active developers
and they don't agree on design and coding style and you have 2
functional implementations which each has its own "champion", its
going to be hard to see a convergence. And, indeed, Torben has moved
along by "forking" the jack1 code and implementing several of the most
important features of jack2 (SMP support, click free graph changes).
He hasn't publically announced this as a fork, and I'm not sure he
really views it that way.
For myself, I confess to being disappointed and puzzled by my own
reaction to Stephane's implementation. I was a big supporter of a C++
implementation which I felt would bring some clarity to the rather
tangled code in Jack1. I also felt very supportive of his goals for
Jack2, not to mention his insanely hard word porting JACK to OS X
(back when it was just jack1) and Windows and continually grappling
with some of the crazier aspects of OS X integration as part of his
work on JackOSX. I really did feel that it would be an improvement to
switch to his implementation and that things would all get better as a
result of this change (in the long run). However, these feelings have
not materialized for me. I don't know why. I don't find myself
regarding the code base of Jack2 as any easier to grapple with than
Jack1 (there are a few areas where portability is simpler because of
the use of C++ classes and inheritance). Like Torben, there are some
design decisions there that I have questions about. In spite of this,
I've continued to have a high regard for Stephane's work and for
Stephane, if for no other reason (and there are PLENTY of other
reasons) than that he had a clear vision of where JACK should go and
he took it there in a fairly time honored Unix/Linux tradition: rather
than convincing everyone working on/with Jack1, he created new
implementation. djbdns, hello?
Meanwhile, we had Torben's original NetJack protocol which was lacking
in some ways, and so a student/colleague of Stephane's implemented a
new version of NetJack to try to address them. This was done in the
context, the supposition, of an "experimental" or "research-y" type of
effort, rather than being part of a concerted, deliberate effort to
get audio-over-IP working for "the masses". It probably doesn't help
that there have been "expert" users of both versions of NetJACK since
they were created, testing it out, and voicing their satisfactions
over the majority of both implementations' feature set, along with
suggestions for improvements, giving an appearance that both protocols
had their benefits and making it harder to kill one of them or merge
them.
Regarding session management, there was basically almost nobody except
for Nedko who agreed with him about his designs for session
management. Torben finally got sick of the endless bickering about
session management when he felt that a solution was fairly readily
available. The design hasn't pleased everyone, and a few people would
have preferred that it hadn't been committed to Jack1, but more apps
every week are adding support for it and my guess is that it will
become useful. Could anyone have predicted this in January? No. Did we
know that session management was needed? Yes. Did we have a clue of
how we would get there? Maybe Nedko did, but I don't think anyone else
did. I've seen similar things happen with GTK (for example,
ExtendedLayout which has recently jumped off the "discussed for years"
list and turned into an implementation that is being tweaked and
evaluated in a very short time).
And then we have to face the gathering impact of:
(a) more users, many of who don't fall neatly along the desktop /
pro-audio+music divide
(b) more distros actively packaging JACK
(c) the arrival of PulseAudio on many distributions
All of a sudden, what felt like peacefully co-existing worlds of
"trying stuff out and trying to keep as in-sync as possible given
limited man-power" are thrown into a decision in which only one of
them can blessed.
I have to say that I resent this. I understand why its happening, but
I resent it. We didn't write JACK to be part of the desktop
environment, we wrote it as a tool for people doing serious
audio&music work. But because a distribution can't handle a basic
concept like a "virtual package" (and that happens to be the distro
that has spawned more offspring than any other), all of a sudden, the
way that we've worked (or not worked - I'll grant its been a bit
dysfunctional for a while now) is threatened so that you guys can
package "one version".
The architecture of JACK (server plus shared library) makes it more
difficult for the right thing to happen - the right thing being that
anyone can implement their own version of JACK and if its compliant
then anyone can use it at any time. Those who use JACK *today*
understand this and my impression is that its actually a somewhat
valued feature that both JACK implementations exist. I can understand
why newcomers to this ecosystem would not share their opinion. And so
perhaps its right to at least have a more upfront discussion about the
future of JACK's versions. I tried to instigate this with NetJACK
several months ago, and although in the meantime, NetJACK1 has
improved in some subtle but important ways, we are no closer to a
single network protocol than we were then. Should we be? Is it a
requirement that we get there? Is it a requirement that users *must*
choose one of jack2 or jack1, when (almost) all the tools will work
just fine with either version? All the tools, that is, except for
debian's packaging system.
Clearly, we can't dispose of that. But to what extent should the
future development path of JACK be determined by the limitations of
packaging systems?
Does anyone really want to have to choose between JACK1 and JACK2 (and
tschak? perhaps) on a permanent basis? Does anyone want to step up and
make the hard decision about NetJACK1 or NetJACK2? Can that decision
even *be* made? Is that supposed to be my job?
--p
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Sat Apr 17 00:15:08 2010
This archive was generated by hypermail 2.1.8 : Sat Apr 17 2010 - 00:15:08 EEST