Re: [LAD] [Jack-Devel] distros migrating to JACK2?

PrevNext  Index
DateFri, 16 Apr 2010 21:36:35 +0200
From Adrian Knoth <[hidden] at drcomp dot erfurt dot thur dot de>
ToPaul Davis <[hidden] at linuxaudiosystems dot com>
Cc[hidden] at lists dot jackaudio dot org, [hidden] at lists dot linuxaudio dot org
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: [hidden]  	http://adi.thur.de	PGP/GPG: key via keyserver
PrevNext  Index

1271446636.21993_0.ltw:2,a <20100416193635.GQ12148 at ltw dot loris dot tv>