On Fri, Apr 16, 2010 at 3:36 PM, Adrian Knoth <a...@drcomp.erfurt.thur.de> 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@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev