On Fri, Apr 16, 2010 at 10:31:08AM -0400, Paul Davis wrote: > > First, we can't have virtual packages for shared libraries in Debian, so > > we cannot provide two different versions of libjack. > 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
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. If you see http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt there's only a single virtual library package (libc-dev). There might be a way to handle it, but this would require us to put everything into a single package, let's say jackd1.deb and jackd2.deb both cater to the virtual package jackd. > > That said, we expect upstream to provide at least one feature-complete > > jackd implementation. This means DBUS support (pulseaudio integration), > > jack-session support, ladish support or whatever the feature should be, > > e.g. SMP. > > 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. 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. For real pros, there's still the second unoccupied card. Or third. 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. ;) 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." Nobody said "tschack also has SMP and even performs better than jackd2", nobody said "we're going to have jack-session support in jackd1", in general, all communication from the jack team was "jackd2 is more or less a drop-in replacement for jackd1", and the jackd2 camp added "we have fancy SMP, we have fancy card reservation, we have glitchless connections" and the lot. So to the outside, the impression was that jackd1 development got stuck (somewhere around 0.116 or even before) and that jackd2 will be its successor, the development branch, if you want. Renaming it from jackdmp to jackd2 didn't help, sharing the same website, trac and svn didn't help. The jack team (if such a thing exists) never set its goals, whether jackd2 is just a playground, an alternative or the successor. There is no jackd1 roadmap, there was nobody saying "we're going to have SMP as well". And now you wonder why everyone else was under the impression that the world only needs one jackd implementation and picked the one with the higher number? Sit together and agree on some goals. Don't have three incompatible netjack implementations, five session management APIs and four different jackd incarnations just for each corner case. I'm clearly exaggerating here, but that's exactly what was missing in the past: a decent statement to users about goals, features and how things relate to each other. Cheerio PS: jackd2 needs to rename jack_rec to jackrec, jackd1 and jackd2 should share the same manpages (maybe from the same svn branch), netjack command line parameters need to be the same. That's a plea to both, jackd1 and jackd2. Work together, forward your patches, read your tickets. Make it less cumbersome for users, they are the ultimate judges. -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev