Adrian Knoth wrote: > 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.
No, I'm using a Debian and Ubuntu, were it's easy to build dummy packages and I'm using Suse too, were it's much dirtier. I'm doing this just to test a sequencer, my favourite distro is 64 Studio and they ship with the JACK I wish to use. > 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? > Nobody. I don't have money, but at least an Envy24 card around 50 EUR would make an on-board audio device obsolete. > 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." > JACK2 doesn't disconnect clients. The disadvantage: There might be phasing between the left and the right channel. The advantage: Even if your hardware isn't good for usage with Linux audio, you are able to use it, but the quality isn't optimal. > 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. > Users like me who reported their experiences were dissed other users got Apple or Microsoft and there only were the users that were comfortable. And now I'm comfortable, because I do need JACK2, but I'm empathetic with those who prefer JACK1, because I did suffer a lot when JACK1 was default, while I need to use JACK2. There's only one good solution. Every user must have the choice between JACK1 and JACK2. Ralf _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev