jackd won’t wake up

My last post ended with me describing some troubles getting jackd to wake after my laptop went into S3. I managed to get some debug info out of jack after running it as a dbus service through qjackctl:

ERROR: JackAudioDriver::ProcessAsync: read error, skip cycle
ERROR: ALSA: channel flush for playback failed (File descriptor in bad state)

The CPU utilization at this point goes way up.

A quick search turns up a Debian bug #601008 and bugs filed against a number of other Linux distros. There’s also an open ticket on this issue in Jack’s tracker.

So all the right people know about the issue. The Jack folks even recommend a very sane work around which is manually suspend and resume Jack before and after S3 (hacking suspend / resume manually). I like the idea of jack getting a notification over dbus even more though. That would be very clean. Hopefully we’ll see some action on this soon. Till then I’m looking for a work around.

Getting Started with the Awesome Window Manager

I’ve been a Gnome user for a while now. It’s been good to me but I’m a minimalist and lately it feels like I’ve been spending a lot of time fighting against Gnome. This past week I bought a new SSD for my laptop but instead of just copying my system over to this new disk I decided to rebuild it from scratch and give the Awesome Window Manager a try.

First off Awesome is beyond minimal. Get comfortable on the keyboard if you give this a try. I’m a huge fan, the less I have to touch the mouse the happier I am. The one thing that gave me trouble was getting my sound up and running. Here’s how I got to a fix:


Gnome does lots of stuff for you that I didn’t even know was happening. I’m not going to get into the complicated stuff like auto mounting encrypted volumes (that’s for next time). This time It’s the simple stuff: running daemons when you log in.

The Awesome wiki has an Autostart page that was super useful. I grabbed the simple run_once function and put this in rc.lua. This works for starting stuff like xscreensaver:


The problem I ran into with sound was actually related. Squeeze changed the way the jackd server gets started. There used to be an init script that fired it up but no more. Squeeze dropped this behavior and now pushes off the responsibility to user space applications so if you app expects jackd to be running be prepared to start it.

So after installing banshee it freaked out crapping errors all over the console. There were tons of exceptions indicating that lots of the expected Gnome infrastructure was missing but the one that’s actually relevant to why sound wasn’t working is:

Cannot connect to server socket err = No such file or directory
Cannot connect to server socket
jack server is not running or cannot be started

With an error message that says “… or cannot be started” you’d think banshee tried to start jackd but once I started jackd manually the problem went away. So starting jackd when awesome starts up is the answer!

run_once("jackd","-d alsa -d hw:0")

gnome-power-manager and S3 sleep

If you’re on a laptop like me you’ll want gnome-power-manager running. It’s comforting having that battery icon in the tray right? Anyway just throw it in your rc.lua file same as before. Squeeze has great support for my ThinkPad x61s so all of the acpi tool and even the function keys work great for putting my system into S3.

jackd and S3 don’t play nice

The problem I’m dealing with now is that after my laptop wakes up from S3 jackd is hosed. It doesn’t crash outright but I don’t get any sound from Totem or other media players (yeah I prefer Totem over Banshee) so I’ve gotta restart it after I wake up from a suspend.

I’m not sure how to automate this yet. Hopefully it won’t come down to hacking the suspend scripts directly. I’m not even sure where these live … till next time.

Debian Lenny make-kpkg broken with new kernel

If you use make-kpkg to build your kernels and you’re running Lenny you may have had problems building 2.6.34 when it came out. With kernel-package version 11.015 I’m getting the following error:

The UTS Release version in include/linux/version.h
does not match current version:
Please correct this

I’m sure more recent packages have this bug squashed but on Lenny it’s still a problem. What’s happening is make-kpkg is looking for a version string in $(KERN_ROOT)/include/linux/version.h and it’s not there. Every once in a while the kernel maintainers move stuff around and that’s exactly what happened. The UTS_RELEASE definition was moved from $(KERN_ROOT)/include/linux/utsrelease.h to $(KERN_ROOT)/include/generated/utsrelease.h

I found it confusing that the error message lists the version.h file. Turns out this definition has been moved before and when make-kpkg can’t find it in $(KERN_ROOT)/include/linux/utsrelease.h it falls back to version.h in the same directory. So we fix it with a quick patch.

--- ./version_vars.mk	2008-11-24 12:01:32.000000000 -0500
+++ ./version_vars.mk.new	2010-06-29 21:51:50.000000000 -0400
@@ -138,10 +138,10 @@
-UTS_RELEASE_HEADER=$(call doit,if [ -f include/linux/utsrelease.h ]; then  
-	                       echo include/linux/utsrelease.h;            
+UTS_RELEASE_HEADER=$(call doit,if [ -f include/generated/utsrelease.h ]; then  
+	                       echo include/generated/utsrelease.h;            
-                               echo include/linux/version.h ;              
+                               echo include/linux/utsrelease.h ;              
 UTS_RELEASE_VERSION=$(call doit,if [ -f $(UTS_RELEASE_HEADER) ]; then                    
                  grep 'define UTS_RELEASE' $(UTS_RELEASE_HEADER) |                       

Down load version_vars.mk.patch. Copy this patch to /usr/share/kernel-package/ruleset/misc/ and apply it:

zcat version_vars.mk.patch.gz | sudo patch -p1

If you’ve already tried to build your kernel and had it fail because of this bug you should copy the version_vars.mk we just patched to $(KERN_ROOT)/debian/ruleset/misc/ and run make-kpkg again. This should keep you from having to rebuild the whole kernel … which takes an age on my laptop.

Can’t wait for Squeeze to go stable but that always comes with a whole set of new problems 🙂

QNAP 419P Torrent Client

About 6 months ago I purchased a QNAP 419P NAS. I did a bunch of shopping around and settled on this one largely because it’s Linux based, runs on a low powered ARM cpu, and it’s got a pretty active community. After 6 months of operation I can’t say I’m thrilled, but it hasn’t been a complete disaster either.

I bought it to replace an older P4 system I had Frankensteined into a file server. It had an old ATA133 3ware raid card with ~900GB in raid 5. I had it running rtorrent on the console and serving up files using NFS. Pretty basic and it served my purposes just fine. I started running out of disk space so I picked up the QNAP 419P.

The 419P is a departure from my normal setup since everything is done through a web UI. I also mount my files using CIFS so my room mate can mount a drive too. The 419P will allow you to mount CIFS and NFS but the permissions get all borked up and since Linux support for CIFS is pretty good these days (and Windows support for NFS sucks) I made the switch.

Now on to the reason I’m writing all of this down: the torrent client that QNAP packages for the 419P is terrible. It’s custom so in their defense it’s a lot of software to maintain. That said I’ve got no idea why they’re trying to roll their own. There are so many web front ends to rtorrent++ that there’s no excuse to be building your own half-baked web front end.

Now bad UI I can handle but recently the trackers I used have started white listing clients. Naturally the identification string offered up by the QNAP torrent client isn’t on the list. So what to do? Well this is where the QNAP community comes in: package rtorrent++ and a few web front-ends. This is all described in their forums [1] and the person who did the heavy lifiting here is definitely getting a few paypal bucks from me as a thank you.

So I’ve got rtorrent and the front ends running on my 419P but why am I still annoyed? Well for one thing there’s no authentication for it. QNAP spent some time building their auth system and it’s not half bad but from the looks of it there isn’t a way for application developers / packagers to tie into it. So as it is now the web UI for rtorrent is wide open. Even on my home network I like to have at least a login / password.

There may be a way to tie into the QNAP auth infrastructure, or even a way to require some auth for the rtorrent front end (I’m thinking some sort of apache mod_auth foo to get at the URI). In the mountains of spare time I’ve got I’ll take a quick look (thick with sarcasm). For now I’m just happy to be downloading again thanks to the QNAP community.

[1] : http://forum.qnap.com/viewtopic.php?f=146&t=25165