CPU frequency indicator and DIY merchandise

I have been using Natty since Alpha 1 and I'm very happy with the new Unity desktop. It has surely got its bugs, but I almost love it. The drawbacks are that Unity doesn't support GNOME applets and doesn't seem to have a native application launcher yet. The latter problem is easily fixed by installing either GNOME Do or Synapse. The applets, well... are not a big problem either, because I can't remember using any, except for the clock (replaced by an indicator) and the CPU frequency scaling applet, which had always saved me from all the JACK audio timing issues (with a single click).

There is no indicator for selecting CPU frequency scaling mode, so I decided to write my own. I started with Jono Bacon's tutorial here and used cpufreq-selector D-Bus service (bundled with the Gnome applet) to switch between governors. This functionality is also provided by HAL, but HAL is deprecated in favour of DeviceKit, which doesn't support frequency scaling right now. I think I'll have to add a dedicated D-Bus service in the future to get rid of gnome-applets dependency... And this is how it all currently looks:



Thanks to Quickly, an Ubuntu package was a piece of cake. You can install it from here or grab the source from project page in Launchpad. Please report any issues. Thanks!

Another thing that bothers me, is an almost critical bug with the Ubuntu Beanie Hat from Canonical store. It just cannot stand low temperatures in winter and is unsafe to wear outside. I wonder, if there is a Launchpad project to report bugs against Ubuntu merchandise :) Anyway, I came up with a simple workaround, which works if you're not afraid of DIY:

1. Get an ushanka.
2. Attach an Ubuntu button badge (I used a really old one).
3. Have fun with the new Ubuntu ushanka!

Better firewire audio support comes to Maverick

Maverick Meerkat development has started with some big changes on the professional audio front. Last week JACK2 (aka jackdmp) has finally replaced the original JACK in Ubuntu. And that's not all! There are FFADO packages, updated to work with the new firewire stack (alias Juju), which in turn is fully supported by the Maverick kernel. The news made me immediately upgrade to Maverick as soon as I've noticed a new libffado source upload in the Maverick changes feed... For now, I am very pleased with the result. But using JACK2 with a Juju-powered backend may require a little bit of work, that I am going to describe below.

First of all, the new FFADO packages currently fail to build on Maverick, because of a Python policy violation (bug 586821). A fix is underway, but I didn't want to wait and built a quick-and-dirty workaround package. If you like workarounds too, feel free to install libffado binaries from my PPA.

Second, to use the new firewire stack, FFADO needs at least libraw1394-2.0.5, which is also missing from Maverick. Hopefully the new version will be merged or synced from Debian soon (bug 586918), but if you don't want to wait again, you can install the package from my PPA as well. That will work.

Next, the old firewire stack has to be blacklisted. Simply edit /etc/modprobe.d/blacklist-firewire.conf to look like:

blacklist ohci1394
blacklist sbp2
blacklist dv1394
blacklist raw1394
blacklist video1394

#blacklist firewire-ohci
#blacklist firewire-sbp2

Finally, run "sudo update-initramfs -k all -u" and reboot. That's it... One thing to remember is that Juju creates device nodes with /dev/fw* paths without write access by default. This is easily fixed by a little udev tweak (example configuration may be found here).

Just to be safe, I also updated my rtirq settings to increase the priority of firewire_ohci IRQ service. It will not make things faster right now, because rtirq requires a realtime kernel, which has not been updated for Maverick (yet).

I like the fact, that all existing JACK applications work without any extra configuration or recompilation. This includes QJackCtl, Qtractor, SuperCollider, JAMin, energyXT... Only Renoise  started to hang and produce bad noises, until I switched the "Realtime audio CPUs" parameter to 1. Most likely it has something to do with JACK's own multicore support.

Some applications may also display strange port names (like firewire_pcm:0500000000000000_Unknown5_out). Luckily, JACK provides port aliases in the "system:playback_N" form. Aliases seem to work transparently for connecting/disconnecting ports, but QJackCtl will only display them if you set the appropriate option in the setup dialog.

Audio streaming is generally stable most of the time, but I've heard glitches with both the internal firewire controller (Ricoh R5C832 rev 05) and an ExpressCard controller (Texas Instruments XIO2200). So, I would not recommend performing live with Maverick right now. Nevertheless, it is great to see the progressing firewire audio support in Ubuntu. Juju migration is one of the Maverick development targets, and there is a blueprint to track the process.