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