jackd1, jackd2, jackd3, tschack
Hi! 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. 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 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. 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. We might even use alternatives. Could this work? If this is too much trouble, we should stick to our jackd2 plans and wait for jackd3 to come. 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. Cheerio -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: jackd1, jackd2, jackd3, tschack
On Sat, Apr 17, 2010 at 12:37:45PM +0200, Adrian Knoth wrote: jackd2 shouldn't be considered the successor of jackd1, but an alternative implementation. Wauw! Please post a URL to some (more official) summary of the dispute if available somewhere. 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 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. 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. We might even use alternatives. Could this work? If this is too much trouble, we should stick to our jackd2 plans and wait for jackd3 to come. How about this: 1. Rename jack as jackd1, including empty transitional packages. 2. Try package jackd2 with libraries renamed to not clash. 3. Update jackd1 to similarly use renamed libraries. That way no other packages are affected until step 3, where they need to decide which of the libraries to link against. If both implementations really do stay both ABI and API compatible that should not matter, and we can perhaps provide symlinks from one of the libraries to the old unbranched location as a convenience. I imagine that we won't do step 3 before freeze of Squeeze, but might reach the other two quickly. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: jackd1, jackd2, jackd3, tschack
Hi guys,
I'm new to the list but joined to see if I could help with
the {j,tsch}ack{1,2,3} issue. :-)
On Sat, 17 Apr 2010, Jonas Smedegaard wrote:
On Sat, Apr 17, 2010 at 12:37:45PM +0200, Adrian Knoth wrote:
jackd2 shouldn't be considered the successor of jackd1, but an alternative
implementation.
Wauw!
Please post a URL to some (more official) summary of the dispute if available
somewhere.
It's on the jack-devel and linux-audio-dev lists on
16-Apr-2010.
LAD:
http://lists.linuxaudio.org/pipermail/linux-audio-dev/2010-April/thread.html
http://lists.linuxaudio.org/pipermail/linux-audio-dev/2010-April/027285.html
http://lists.linuxaudio.org/pipermail/linux-audio-dev/2010-April/027310.html
(***)
http://lists.linuxaudio.org/pipermail/linux-audio-dev/2010-April/027316.html
Jack-Devel: (must be a member to view archives)
http://lists.jackaudio.org/private.cgi/jack-devel-jackaudio.org/2010-April/thread.html
(Most messages are the same, though.)
How about this:
1. Rename jack as jackd1, including empty transitional packages.
2. Try package jackd2 with libraries renamed to not clash.
3. Update jackd1 to similarly use renamed libraries.
If I understand correctly, the *only* packages that need to
be virtual are libjack and libjack-dev. The actual
libjack-jack1 and libjack-jack2 would then have a dependency
on the jackd implementation.
-gabriel
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: jackd1, jackd2, jackd3, tschack
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 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org
Re: jackd1, jackd2, jackd3, tschack
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
