jackd1, jackd2, jackd3, tschack

[torbenh]

On Sat, Apr 17, 2010 at 03:17:46PM +0200, Reinhard Tartler wrote:
> On Sat, Apr 17, 2010 at 12:37:45 (CEST), Adrian Knoth wrote:
> 
> > Yesterday, somebody digged out Suse's announcement of our coordinated
> > distro approach for switching to jackd2.
> >
> > A lot has happened during the past hours on the mailing lists and via
> > IRC.
> >
> > Basically, the jackd1 camp isn't really happy. And some people think we
> > should really provide a choice which version to use.
> >
> > Foremost, jackd2 shouldn't be considered the successor of jackd1, but an
> > alternative implementation. Think of exim|sendmail|qmail.
> 
> perhaps it shouldn't have been named jackd2 in the first place then, uh?

yeah. it shouldnt. but at the time that happened it seemed right to the
people in charge.
jackdmp was the only other implementation and being SMP capable and 
in c++ it seemed right to them. 



> 
> > So what do we have?
> >
> > jackd1 --> stable, containing jack_session (that's something new)
> > tschack --> jackd1 derivative with SMP support, jack_session
> > jackd2 --> C++ reimplementation, SMP, no jack_session yet, but on the
> >            horizon, card reservation via DBUS (pulseaudio integration)
> > jackd3 --> upcoming C++ reimplementation of jackd1
> 
> I think this amount of variability is just madness. Do we really want to
> support any combination of application and jack daemon listed above? I
> feel we hardly manage to keep a single jack version in shape, and
> increasing the number of combinations to test is not going to make this
> easier.

i wouldnt advocate you support any combination.
i just want that you leave the door open for people who want to install
an alternative. 

iE right now tschack didnt have its share of broad testing.
i have around 10 users. 
and these confirm that it works better than jack2.
thats by no means representative.
(and having problems with jack2 drove them to using tschack... so far
this is a 100% success rate that it indeed fixed peoples problems with
jack2)

i myself dont have problems with jack2 (except its codebase ;)
so if i were to play a gig, i would use jack2 since its got a broader
testing) 

> 
> > If we can only have one jack version in Debian, we probably really use
> > jackd2 now, mostly because of card reservation. However, this would more
> > or less be a version lock-in.
> 
> I wouldn't necessarily consider such a lock-in as bad, as it reduces the
> number of tests, see above.

i am not advocating that you use a broader testing base. i dont even
mind you really do the switch and drop jack1.
but you should still leave the door open via a virtual libjack0
dependency so that its possible to provide alternative jack packages.

> 
> > Perhaps we should free ourselves and come up with a solution that allows
> > for different jackd implementations in Debian. Other distros can do
> > this, too. ;)
> >
> > We can't make libjack0 virtual, right? Can we put everything into a
> > single package, let's say jackd1 and jackd2, both containing the stuff
> > which is now present in libjack0, libjack-dev and the jackd package
> > itself? And then let them all Provide: jack-audio-connection-kit
> > or something like this.
> 
> Technically, we could play tricks with the shlibs file, I'm doing such
> dirty tricks already in the FFmpeg package, and I think it could work
> with jack as well. For this, we would need to decide which
> implementation is going to provide the headers and library that shall be
> used for application packages at build time. The "trick" would be this:
> 
>  - rename the library package libjack0 to libjack0-jackd1
>  - make 'libjack0-jackd1' provide 'libjack0'
>  - introduce other implementations in the same way, e.g.,
>    libjack0-jackd2 would provide libjack0 as well
>  - install a (common) shlibs file in all implementations to  make
>    application packages refer to libjack0 in their dependencies
>  - pray that we will never need to bump shlibs
> 
> The obvious drawback of this madness is that we cannot use versioned
> dependencies anymore. E.g. newer jack libraries after 0.116.2 introduced
> some new symbols. If some application does not work with an earlier
> version than 0.116.2 of jack, then we cannot express that situation in
> terms of package dependencies anymore. In that case we need to rename
> the name of the virtual package, e.g., libjack0a and recompile the
> world!

all these symbols after 0.116.0 are weak.
and they are only "optional" stuff. every app needs to check for their
presence and would only activate some functionality if it finds these
symbols.

and app using these symbols without checking is buggy.

> 
> I don't know about the implementation of jackd1 vs. jackd2 or future
> implementation, but my impression of this whole mess makes me feel that
> something like this is not unlikely at all, despite the fact upstream is
> trying really hard to preserve both forward and reverse binary
> compatibility.
> 
> And now a reality check: currently, libjack0's shlibs file looks like
> this:
> 
> ,----[/var/lib/dpkg/info/libjack0.shlibs]
> | libjack 0 libjack0 (>= 0.118+svn3796)
> | libjackserver 0 libjack0 (>= 0.118+svn3796)
> `----
> 
> this means that we already declare that applications that have been
> built against squeeze's libjack won't work with lenny's libjack0. If
> this is really the case, then we have already lost.

well.. lenny seems to be using jack-0.109 and thats in fact very old.
and here stuff wont work. true.

0.109 was lacking jack-midi support iirc.

> 
> 
> > We might even use alternatives. Could this work?
> 
> the Debian science team is doing something very similar to this as
> well. The release team first had some concerns, but eventually agreed to
> this approach. I'd rather like to avoid it because of the reasons
> outlined above.
> 
> > If this is too much trouble, we should stick to our jackd2 plans and
> > wait for jackd3 to come.
> 
> this would only defer the problem to later, AFAIUI.
> 
> I'm thinking about something like the nvidia vdpau approach: introduce a
> new abstraction lib, that checks at runtime for available real
> implementations and uses them then. But given that the jack API is not
> exactly trivial, this might be infeasible as well :-(

not feasable. and really bad.

> 
> > However, there has already been one good result: somebody is coding
> > jack-session for jackd2 now, because if we really move to jackd2, it
> > wouldn't make sense to only have it in jackd1.

it had to be done sooner or later.
it was just that sombody had vlounteered to do it, and he didnt.
this stuff just triggered that i didnt wait any longer.

> 
> How about implementing a pulseaudio module that implements the jack ABI?

it would actually make some sense. 
but for people who want to use low-latency stuff. it would make no sense
to use this. 

it would be just another jack implementation. and really the worst of
them all. (if you measure this by latency) so for people who want to
make music it would be unusable. 

without a virtual libjack it would make no sense at all. 

there are lots of different ways to implement the jack ABI.
but since all these implementations will be measured by achievable
latency they are all really different if you look at them closer.

linux is about choice. dont block it. make it possible.

> 
> -- 
> Gruesse/greetings,
> Reinhard Tartler, KeyID 945348A4
> 
> _______________________________________________
> pkg-multimedia-maintainers mailing list
> pkg-multimedia-maintainers at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

-- 
torben Hohn