Team Meeting Sunday 11-01-09 [aka this Sunday]
nedko at arnaudov.name
Fri Jan 9 20:08:00 GMT 2009
"Cory K." <coryisatm at ubuntu.com> writes:
> Cory K. wrote:
>> Sunday, January 11th @20:00 in #ubuntustudio-devel. Should be early
>> Monday morn for Luke and Emmet.
First, sorry for late reply.
My whole Sunday is unavailable so I'm not able to participate. Also I'll
have less time for opensource things starting from Monday because by
holiday (about a month now) is ending. As most of the team expect me to
participate especially in discussion of jack2 maybe best will be for you
to discuss it without me and give some summary in a mail so I can
comment. I'm giving my initial thoughts on this and other subjects:
> Our action items look to be:
> * Transition to Jack2 (make detailed action plan)
Some backgroud first:
Some years ago Stephane Letz created jackdmp, a full rewrite of
jack. The reason for such rewrite is to fix some problems with the
jack-0.x code that cannot be fixed with minor changes because they are
caused by the software architecture in general. Probably the most
important such issue that affects Ubuntu is the SMP support.
During last year, after LAC2008 in March jack got some boost in
developement and grow in momentum. The two codebases merged in single
repository and shared development infrastructure (trac.jackaudio.org).
Now about the jack D-Bus interface and my involvement in JACK. In the
last months of 2007 I started the LADI project, an initiative for better
integration of software components that form infrastructure linux audio
with desktop and make them more user-friendly. The project got name -
LADI (Linux Audio Desktop Initiative) and some followers, both
developers and testers. In the scope of this meta-project are JACK, LASH
and Patchage. Later a2jmidid emerged. One of things that was missing is
jack operating as background service, with log file and way to control
it and configure it regardless of the GUI frontend used. These issues
applied to LASH as well, plus the fact that it didnt really worked (for
me). I realized that the gainging popularity D-Bus technology is the
best way to fix most of these issues. So I made patch that allowed JACK
server to be controlled and monitored through D-Bus layer. I've made
JACK to have settings file that persists settings that are modified
through D-Bus and also when D-Bus session bus daemon activated JACK, all
diagnostic was delivered to a log file. Unfortunately the whole D-Bus
idea got heavy resistance in lad and jack-devel mailing
lists. Fortunately some people liked the idea and advocated it on
LAC. The main effect was that jackdmp/jack2 (Stephane Letz) accepted
jackdbus idea. This lead to heavy colaboration and by the end of this
year jack2 got first release, 1.9.1, that includes dbus as option. The
old jack1 code was not lost but is less maintained and is things here
and there are not implemented. ATM jack1 dbus code is maintained as a
GIT branch of jack1 trunk and I release sync-ed tarballs with each jack1
Now about LASH, LASH was dbusified during 2008 too. Juuso Alasuutari got
paid Summercode project and with little help with me, now we have
0.6.0~rc2 that is major refactoring of the code without significant
features added but with some important workflow fixes.
As I wanted to use JACK MIDI with -X raw backend for hardware devices I
was left with no option for the apps that still use ALSA seq
framework. So I created a2jmidid, I used the Dmitry Baikov's code. Its
code now lives in two other "forks", the jack1 -X seq MIDI backend and
the jack2 -X seq MIDI backend.
Me and Marc-Olivier Barre combinded efforts on the LADITools project
(formely known as pyjackctl). It contains some UI frontends for JACK
* laditray - tray application for monitoring and controlling JACK,
LASH and a2jmidid.
* ladiconf - configuration utility that allows configuration of the
LADI components in single place (currently only JACK has
* g15ladi - shows JACK status on LCD display of the Logitech G15
* ladilog - alternative of using terminal & tail to watch log files of
* wmladi - WindowMaker-style dockapp for monitoring and controlling
LADI components (this is what I mainly use dayly).
laditools has a release candidate, laditools-1.0-rc1
Patchage is the app I use on daily basis to patch JACK apps. So I
improved it, some of changes got upstream some not. The situation ATM is
that I maintain a GIT branch of the Patchage code and the patchage from
it is installed as lpatchage so it can coexist with the upstream
Patchage. LADI Patchage It is mainly oriented toward being a LASH
dashboard with canvas JACK patchbay. It does not support patching ALSA
seq but has integration for a2jmidid. Thus, lpatchage presents single
type MIDI connections to user while still allowing to patch legacy ALSA
As you can see to make things work for me (and hopefully for other ppl
too) I did some forks here and there and some of them will probably be
never be merged upstream. This imposes some problem WRT Ubuntu because
while I'm upstream developer, I'm not representative (in fact i'm kind
of opposition) of some of them. The packages I've made in hope for
better quality of LADI components in Ubuntu are made for components I
beleive to be the right ones.
Now back to JACK subject:
The first step in integration of LADI in Ubuntu is of course
JACK. Because of dbus resistance for jack1 codebase, jack2 is much
better choice for ppl who share the LADI vision. jack2 is expected to be
jack1 drop-in replacement. I.e. this means it is ABI and API backward
compatible. This is the goal and I think it is in good shape (from my
tests). Of course jack is big and complex software and because of bugs
some apps may have problems. Such bugs usually are addressed with high
Currently there is a package for jack-1.9.0 in ubuntustudio-dev PPA and
in REVU. There are some major issue that are fixed upstream after the
1.9.0 release. They may or may not affect large userbase. I personally
use latest svn but of course I'm not typical Ubuntu user, in fact I dont
even use Ubuntu on daily basis. I have Ubuntu Hardy installation that I
We talked with Khashayar and others on IRC about maintaing JACK2 for
Jaunty and backports for Hardy and others. As I have limited experience
with packaging and package deployment I only can say that it will be
useful for me of they are maintained as separate bzr branches with
1. upstream branch merged to main packaging branch (that should follow
lateset targeted Ubuntu release, currently Jaunty)
2. general packaging changes are made first to the main packaging
3. main packaging branch is merged to backport branches, one per
release. Packaging changes specific to Hardy for example should be
made in the Hardy branch
WRT my participation in packaging for Jaunty. While I still beleive
Ubuntu is very important distribution and should have high quality LADI
packages my upstream involvement gets higer priority. Also I'm doing
software to earn money so I'm not really the one that can be relied upon
for opensource work, espessially when it is involving timelines and
deadlines. Please dont take this as offense or something liek this
against Ubuntu, it is not. I just want to be clear on what I can
contribute so nobody gets false expectations and bad feelings.
> * Dropping pulseuadio for audio task (decide plan, details and action)
I never used pulseaudio so I can't give any feedback on this.
> * Welcome khashayar1 to the team
Welcome Khashayar! Nice to have one more person interested on JACK in Ubuntu!
> * Seed review. (there have been a couple of replacements on our part and I'm sure Ubuntu has some as well)
No idea what this is
> * JACK in main (requires FFADO iirc?)
I'm not really interested in jack1 packages so I cant contribute.
> * Proper use of our PPA.
I'm very interested on this but I have little experience with packaging
and package deployment so I probably cant contribute on this topic
> * Backport package list.
I cant give feedback as I'm not really using Ubuntu.
> * Prepare for Alpha3
No idea what this is
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 188 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/ubuntu-studio-devel/attachments/20090109/5bc14cf6/attachment.pgp
More information about the Ubuntu-Studio-devel