jackd1, jackd2, jackd3, tschack

[Reinhard Tartler]

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?

> 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.

> 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.

> 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!

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.


> 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 :-(

> 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.

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

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4