Quick update for all K-lovers: apply this patch to xine-lib and enjoy PulseAudio in Amarok and other KDE apps without stability issues. It's a race-free rework of Diego's original patch.

Just three words: awesome awesome awesome.

And for those asking for it, here are my slides, in which I try to explain the new "glitch-free" audio scheduling core of PulseAudio that I recently commited to the glitch-free branch in PA SVN. I also try to make clear why this functionality is practically a *MUST* for all people who want to have low-latency audio, minimal power consumption and maximum drop-out safety for their audio playback. And thus, why all those fancy embedded Linux devices should adopt it better sooner than later. The slides might appear a bit terse if you don't have that awesome guy they usually come with presenting them to you.

After coming back from my somewhat extended linux.conf.au trip I spent the whole day grepping through email. Only 263 unprocessed emails left in my inbox. Yay.

PRTPILU

Thanks to the LCA guys, video footage is now available of all talks, including my talk Practical Real-Time Programming in Linux Userspace (Theora, Slides). In my endless modesty I have to recommend: go, watch it, it contains some really good stuff (including me not being able to divide 1 by 1000). Right now, the real-time features of the Linux kernel are seldomly used on the desktop due to a couple of reasons, among them general difficulty and unsafety to use them but predominantly it's probably just unawareness. There are a couple of situations however, where scheduling desktop processes as RT makes a lot of sense (think of video playback, mouse curse feedback, etc.), to decouple the execution (scheduling) latency from the system load. This talk focussed mostly on non-trivial technical stuff and all the limitations RT on Linux still has. To fully grok what's going on you thus need some insight into concurrent programming and stuff.

My plan is to submit a related talk to GUADEC wich will focus more on actually building RT apps for the desktop, in the hope we will eventually be able to ship a desktop with audio and video that never skips, and where user feedback is still snappy and quick even if we do the most complicated IO intensive processing in lots of different processes in the background on slow hardware.

I didn't have time to go through all my slides (which I intended that way and is perfectly OK), so you might want to browse through my slides even if you saw the whole clip. The slides, however, are not particularly verbose.

Rumors

Regarding all those rumors that have been spread while I -- the maintainer of PulseAudio -- was in the middle of the australian outback, fist-fighting with kangaroos near Uluru: I am not really asking anyone to port their apps to the native PulseAudio API right now. While I do think the API is quite powerful and not redundant, I also acknowledge that it is very difficult to use properly (and very easy to misuse), (mostly) due to its fully asynchronous nature. The mysterious libsydney project is supposed to fix this and a lot more. libsydney is mostly the Dukem Nukem Forever of audio APIs right now, but in contrast to DNF I didn't really announce it publicly yet, so it doesn't really count. ;-) Suffice to say, the current situation of audio APIs is a big big mess. We are working on cleaning it up. For now: stick to the well established and least-broken APIs, which boils down to ALSA. Stop using the OSS API now! Don't program against the ESD API (except for event sounds). But, most importantly: please stop misusing the existing APIs. I am doing my best to allow all current APIs to run without hassles on top of PA, but due to the sometimes blatant misues, or even brutal violations of those APIs it is very hard to get that working for all applications (yes, that means you, Adobe, and you, Skype). Don't expect that mmap is available on all audio devices -- it's not, and especially not on PA. Don't use /proc/asound/pcm as an API for enumerating audio devices. It's totally unsuitable for that. Don't hard code device strings. Use default as device string. Don't make assumptions that are not and cannot be true for non-hardware devices. Don't fiddle around with period settings unless you fully grok them and know what you are doing. In short: be a better citizen, write code you don't need to be ashamed of. ALSA has its limitations and my compatibility code certainly as well, but this is not an excuse for working around them by writing code that makes little children cry. If you have a good ALSA backend for your program than this will not only fix your issues with PA, but also with Bluetooth, you will have less code to maintain and also code that is much easier to maintain.

Or even shorter: Fix. Your. Broken. ALSA. Client. Code. Thank you.

Oh, if you have questions regarding PA, just ping me on IRC (if I am around) or write me an email, like everyone else. Mysterious, blogged pseudo invitations to rumored meetings is not the best way to contact me.

To whom it may concern: I finally moved from Hamburg (Wohldorf) into my new flat in Berlin (Friedrichshain).

To whom it may concern: as a first step to move away from SVN and towards GIT for all my code, I have now configured live GIT mirrors for all my SVN repositories. The plan is to move fully to GIT, but not as long as the GIT integration into Trac is as painful as it is right now. The scripts I used to initialize and update the mirrors are svn-live-init and svn-live-update, for those interested. They are based on scripts CJ van den Berg supplied me with.

It would be great to have the mirror to be both ways. Lazyweb, do you know how to do that?

I finally found them time to sit down and update my venerable Avahi/Zeroconf patch for distcc. A patched distcc automatically discovers suitable compiler servers on the local network, without the need to manually configure them. (Announcement).

Here's a quick HOWTO for using a patched distcc like this:

• Make sure to start distccd (the server) with the new --zeroconf switch, This will make it announce its services on the network.
• Edit your $HOME/.distcc/hosts and add +zeroconf. This magic string will enable Zeroconf support in the client, i.e. will be expanded to the list of available suitable distcc servers on your LAN.
• Now set $CC to distcc gcc globally for your login sessions. This will tell all well-behaving build systems to use distcc for compilation (this doesn't work for the kernel, as one notable exception). Even better than setting $CC to distcc gcc is setting it to ccache distcc gcc which will enable ccache in addition to distcc. i.e. stick something like this in your ~/.bash_profile: export CC="ccache distcc gcc"
• And finally use make -j `distcc -j` instead of plain make to enable parallel building with the right number of concurrent processes. Setting $MAKEFLAGS properly is an alternative option, however is suboptimal if the evalutation is only done once at login time.

If this doesn't work for you than it is a good idea to run distcc --show-hosts to get a list of discovered distcc servers. If this list isn't complete then this is most likely due to mismatching GCC versions or architectures. To check if that's the case use avahi-browse -r _distcc._tcp and compare the values of the cc_machine and cc_version fields. Please note that different Linux distributions use different GCC machine strings. Which is expected since GCC is usually patched quite a bit on the different distributions. This means that a Fedora distcc (the client) will not find a Debian distccd (the server) and vice versa. But again: that's a feature, not a bug.

The new -j and --show-hosts options for distcc are useful for non-zeroconf setups, too.

The patch will automatically discover the number of CPUs on remote machines and make use of that information to better distribute jobs.

In short: Zeroconf support in distcc is totally hot, everyone should have it!

For more information have a look on the announcement of my original patch from 2004 (at that time for the historic HOWL Zeroconf daemon), or read the new announcement linked above.

Distribution packagers! Please merge this new patch into your packages! It would be a pity to withhold Zeroconf support in distcc from your users any longer!

Unfortunately, Fedora doesn't include any distcc packages. Someone should be changing that (who's not me ;-)).

You like this patch? Then give me a kudo on ohloh.net. Now that I earned a golden 10 (after kicking Larry Ewing from position 64. Ha, take that Mr. Ewing!), I need to make sure I don't fall into silver oblivion again. ;-)

A couple of minutes ago I released Avahi 0.6.22 into the wild, the newest iteration of everyone's favourite zero configuration networking suite.

You ask why this is something to blog about?

Firstly, new in this version is Sjoerd Simons' avahi-gobject library, a GObject wrapper around the Avahi API. It allows full GObject-style object oriented programming of Zeroconf applications, with signals and everything. To all you GNOME/Gtk+ hackers out there: now it is even more fun to hack your own Zeroconf applications for GNOME/Gtk+!

Secondly, this is the first release to ship i18n support. For those who prefer to run their systems with non-english locales^[1] this should be good news. I've always been a little afraid of adding i18n support, since this either meant that I would have contstantly had to commit i18n patches, or that I would have needed to move my code to GNOME SVN. However, we now have Fedora's Transifex, which allows me to open up my SVN for translators without much organizational work on my side. Translations are handled centrally, and commited back to my repository when needed. It's a bit like Canonical's Rosetta, but with a focus on commiting i18n changes upstream, and without being closed-source crap.

You like this release? Then give me a kudo on ohloh.net. My ego still thirsts for gold, and I am still (or again) 25 positions away from that. ;-)

Footnotes

[1] Personally, I run my desktop with $LC_MESSAGES=C, but LANG=de_DE, which are the settings I can recommend to everyone who is from Germany and wants to stay sane. Unfortunately it is a PITA to configure this on GNOME, though.