Excerpts from Adrian Knoth's message of 2010-04-16 11:21:12 +0200: May I ask for the reasoning behind this? Personally I don't see jack2 as a successor to jack1. Regards, Philipp

On Fri, Apr 16, 2010 at 10:15 AM, Adrian Knoth <adi(a)drcomp.erfurt.thur.de> wrote: i don't understand this. either i'm not understanding the point, or it sounds likea debian-specific limitation. i use fedora+ccrma, which has jack2. i removed jack2 (--nodeps) and overlaid jack1. all fedora packages that relate to JACK continue to work normally. am i not understanding what you mean? this seems entirely reasonable. this is understandable, if less reasonable. at this point in time, the bugs in jack2 are entirely different bugs from the bugs in jack1. the existence of a bug in either version doesn't predict the status of that functionality in the other. this seems sort of right, although only as long as you use "jack" to refer to the library+server and not any of the front end control apps,patchers etc. this is where things really fall apart because it presupposes agreement on the feature set, an agreement which as i think you know just isn't there. I understand the sentiment, but I am not sure that this is likely to have this result.

On Fri, Apr 16, 2010 at 3:36 PM, Adrian Knoth <adi(a)drcomp.erfurt.thur.de> wrote: I'll happily deal with the rest of the email later, but I just want to note that I very strenously object to being lectured about how the JACK project should behave. There have been some serious errors in what has happened, when viewed from both the inside and the outside. But the reasons why these things have happened is not rooted in malice, or confusion, or lack of communication, and it doesn't help the situation at all to suggest that the solution is just "sit down and agree on some goals". lack of common goals is very far from the problem here.

On Fri, Apr 16, 2010 at 09:55:56PM +0200, Ralf Mardorf wrote: Feel free to enlighten me how to provide both, jackd1 and jackd2 in Debian. I'm happy to please both camps, if possible. Could you elaborate on this? I don't understand it. http://linuxhaters.blogspot.com/2008/07/fallacy-of-choice.html -- mail: adi(a)thur.de http://adi.thur.de PGP/GPG: key via keyserver

On Fri, Apr 16, 2010 at 3:36 PM, Adrian Knoth <adi(a)drcomp.erfurt.thur.de> wrote: That's pretty pathetic. But I guess there's not much to be done about that. 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. if they are not connecting JACK to their el-cheapo laptop card, then the issue doesn't arise, does it? 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

On Fri, 16 Apr 2010 16:33:00 -0400 Paul Davis &lt;paul(a)linuxaudiosystems.com&gt; wrote: <snip> Thank you for going to the trouble to post this very clear and detailed explanation. -- Will J Godfrey http://www.musically.me.uk Say you have a poem and I have a tune. Exchange them and we can both have a poem, a tune, and a song.

On Fri, Apr 16, 2010 at 11:21:12AM +0200, Adrian Knoth wrote: great... many thanks. :((((((( -- torben Hohn

Am Freitag, den 16.04.2010, 18:52 +0200 schrieb Ralf Mardorf: I hope, when debian switch to jack2, they will make it in one packet (maximal a second for the dev files), that's what could make it easer to switch the version for people how like to switch. + 2 cents hermann

On Friday 16 April 2010 19:23:33 Ralf Mardorf wrote: Hopefully they will think again before following this. Why should all users get the files on their disks that are needed only for debugging and developing? Disk-space might not be an issue with your state-of-the-art-all-inclusive machine, but not everyone has such a thing. Some have older machines still running with <20GB disk, some have netbooks with only small (but fast!) solid state disks. Now why again should they install gigs of headers and debugging-symbols when they just need the libs and apps to run jack and assorted? Arnold

Arnold Krille wrote: Arnold, I don't have much money. 1. A hard disk isn't expensive. 2. For e.g. 64 Studio 3.0-beta3 amd64 libjack0.100.0-dev does need 61.4 kb and not gigs. I'm just talking about JACK. 3. Who does use Linux audio and doesn't need libjack-dev? 4. Who does produce music on a 20GB hard disk? C'mon ;)! IMHO it would be good once and for all to clear all issues because of packages for JACK and IMHO the best way seems to be to have everything that is JACK in one package. :) Ralf

Ralf Mardorf wrote: PS: "Major distros" does include a lot of stuff that isn't needed by everyone and that's absolutely okay, e.g. pulseaudio and DBUS, games, office suites etc. ...

Hi, On Friday 16 April 2010 19:55:49 Ralf Mardorf wrote: Sometimes a big hard-disk is not a question. Sometimes you use hardware that can't use big hard-disks. When you start with one package to contain both (debugging) binaries and headers, you will go on with all of them. Now lets see how big debug-symbols and headers from KDE, Qt, Gnome, firefox and openoffice are. People distributing their own packages in their "private" network. Only the package-building machine needs the dev-packages. I didn't say anything about producing, did I? The machine is meant to do "master"-processor for listening, both digital- room-correction for at-home and live-foh-master. Don't need much disk their. And newer disks with fine mechanics and narrower tracks on the disk are less fault-tolerant with respect to noise likely to be present at the foh. Originally that machine was to run from a 4GB CF-Card. Only the motherboard wouldn't boot from it. Now, why again should that machine have all the dev-stuff installed again? Why should sound-installations have the complete development-chain installed? I thought that it would be okay for jack to packaged with both server and client-lib in one package. But considering that I have libpulse installed to make apps looking for pulse happy, while the pulseserver is not installed (to make me happy), I have come to the conclusion, that jack also has to be split in server and client libs (and development packages!). That way your favourite music player can have an output plugin that looks for jack and if that is not running, looks for pulse and finally choose direct alsa for playback... Have fun, Arnold

Ok Marije, Arnold, Philipp :) programs don't depend to the development files, so I perceive that they should be separated. Today for 64 Studio 3.0-beta3 = Ubuntu Hardy we do have a package jackd including /usr/bin/jackd. A package jackdbus including nothing but copyright, TODO etc.. A package libjack0, including /usr/lib/libjack.so. A package libjack0.100.0-0, including nothing but copyright, TODO etc.. A package libjack-dev, including the headers. A package libjack0.100.0-dev, including nothing but copyright, TODO etc.. And than there are the libjackserver packages, IIRC there aren't such packages for Karmic. Again, I'm using JACK2, I prefer JACK2, I won't have any issues when JACK2 will become default for all distros, but other people might like to keep JACK1. Because at the moment JACK1 is default for some distros, I know the troubles, when I changed to JACK2 or when I just compiled the current version of JACK1, like I did for Karmic, fortunately my favourite distro already ships with JACK2. For Karmic I've got 5 dummy packages and one package that really is needed. $ ls /media/disk/usr/src/dummy-packages jackd_0.118.0_all.deb libjack0.100.0-0_0.118.0_all.deb libjack-dev_0.118.0_all.deb libjack0_0.118.0_all.deb libjack0.100.0-dev_0.118.0_all.deb $ ls /media/disk/usr/src/jack-audio-connection-kit-0.118.0/*.deb /media/disk/usr/src/jack-audio-connection-kit-0.118.0/jack-audio-connection-kit_0.118.0-1_i386.deb For Suse I don't know how to build dummy packages, first I ignored the broken dependencies when doing upgrades, then I have had enough and installed the regular packages, deleted all files and build the version of JACK I wish to have. I don't understand the reason why this can't be changed. 2 Cents, Ralf

On Sun, Apr 18, 2010 at 11:09:53AM +0200, Philipp wrote: Stop that FUD. Ok, a lot was broken until last year, but I fixed everything and worked closely together with upstreams. If you have something that needs improvement, simply tell me. In general, calling the pro-audio stack in Debian to be broken is barely justifiable. Hint: Torben uses Debian unstable. Of course, I cannot be held responsible for our spin-offs like Ubuntu in all its incarnations (studio, xubuntu, kubuntu, whatever). Old stuff. Check the expiry date of your truths. Reality changes over time. -- mail: adi(a)thur.de http://adi.thur.de PGP/GPG: key via keyserver

Excerpts from Adrian Knoth's message of 2010-04-18 11:25:57 +0200: I know. When I refer to debian I usually mean those spinoffs as well. It's not expired as long as lots of people use the broken versions. Good if you managed to fix it. What was the topic again?

On Sun, Apr 18, 2010 at 11:44:54AM +0200, Philipp wrote: We're working on it. "it" as in "different jack implementations in Debian". Historically, we only had jackd1, but I guess we'll at least see jackd1 and jackd2, perhaps also tschack, and the user will be able to choose whatever he likes. Precompiled, officially supported, easy and working out of the box. Once the technical discussion has settled, it will take us some weeks to actually implement it, but I'm confident that it will happen. I think we can close the thread now, every argument is already on the table. It's now all about the details, but that's our business. And we're glad to cooperate with Torben and Gabriel to make it right. ;) Cheerio -- mail: adi(a)thur.de http://adi.thur.de PGP/GPG: key via keyserver

Philipp wrote: I could add a list of broken packages for [censorship to avoid a flame war]. That's why I guess every Linux audio user running a distro that isn't a pure audio distro and sometimes even for pure audio distros needs to compile apps depending to the JACK headers. We only need one package for each JACK named jackx-audio-connection-kit and at best a second one called jackx-audio-connection-kit-dev, x is for 1, 2, 3, dbus or what ever, for the dependencies there should be added that JACK1 conflicts with JACK2 etc., thus the averaged user is able to choose the version of JACK he wishes to have. Ralf

On 19 April 2010 01:42, Arnold Krille &lt;arnold(a)arnoldarts.de&gt; wrote: http://www.archlinux.org/packages/extra/i686/jack/files/ We do not believe in the extra work of splitting package files for no added benefit. One package is everything upstream releases, i.e software -> package -> user. Simple. -- GPG/PGP ID: B42DDCAD

On 19 April 2010 02:57, Ralf Mardorf &lt;ralf.mardorf(a)alice-dsl.net&gt; wrote: jack is and will for the lifetime of jack1 be jack1 in Arch's [extra] repository. When jack2 will be included depends on an upstream milestone and someone eventually requesting that inclusion - it doesn't affect the existence of a jack1 package :) You may have chanced upon something talking about the ArchAudio project, the repositories of which do provide builds of jack2. It's not an official project. In any case, the jack2 packages just conflict with jack, there aren't any (virtual) problems. -- GPG/PGP ID: B42DDCAD

Excerpts from Arnold Krille's message of 2010-04-18 19:42:00 +0200: Jack isn't started automatically in every case, it depends on the app, and afaik very few do it. So you're effectively only reducing the size of the packages the user has to install as dependencies of the music player. I do package myself a little bit, and the package management system is probably a few orders of magnitude simpler than apt, and so is the packaging, but the basic issues are the same everywhere. You always have to find the 'right' balance between features and dependencies. Simplified, users want every feature but no dependency. There's no way to do it, so you have to find a balance. The debian-like system compiles the package with every feature but the user only needs to install half the dependencies, and some more if he wants to use the features. The gentoo-/arch-like system allows the user to easily recompile and install the package with whatever features he wants. It's maybe a bit simplified, but that's how I see it. I don't know how much trouble the absence of part of the program causes. In my experience it can be quite bad, but there are some notable cases where the developers did a good job. Example: moc A music player that can be compiled with wavpack support, but if wavpack is missing at runtime there's no problem, you simply can't load wavpack files into it. I wish more programs would work like that. Arch Linux, the one I'm using these days. My motto is: "Work with upstream." So far my experience was great in that respect. Most developers are happy about feedback and willing to help resolve packaging issues. On a sidenote, I don't want to start a flamewar and discuss the merits of different distributions. The differences are huge in some areas and all have their benefits. While I switched from a debian derived distro (ubuntu) and am very happy with the benefits Arch Linux offers I really respect debian for the idealism and the broad spectrum the project tries to cover. Regards, Philipp

Glad I use a distro that gives me choice. Enjoy yours. -- Christopher Cherrett ccherrett(a)openoctave.org http://www.openoctave.org

-------- Original Message -------- Subject: Re: [LAD] distros migrating to JACK2? From: Ralf Mardorf &lt;ralf.mardorf(a)alice-dsl.net&gt; To: Christopher Cherrett &lt;ccherrett(a)openoctave.org&gt; Cc: linux-audio-dev(a)lists.linuxaudio.org Date: 04/16/2010 12:36 PM I really don't want the others to feel like they are trapped so I best not say anything :) -- Christopher Cherrett ccherrett(a)openoctave.org http://www.openoctave.org

hermann wrote: Yep! Gentoo or Linux from the scratch ... hm ... eventually Arch?