The Call for Papers for the Linux Plumbers Conference (LPC) in September in Portland, Oregon is ending soon, on June 15th 2009. It's a conference about the core infrastructure of Linux systems: the part of the system where userspace and the kernel interface. It's the first conference where the focus is specifically on getting together the kernel people who work on the userspace interfaces and the userspace people who have to deal with kernel interfaces. It's supposed to be a place where all the people doing infrastructure work sit down and talk, so that each other understands better what the requirements and needs of the other are, and where we can work towards fixing the major problems we currently have with our lower-level APIs.

Last year's conference was hugely successful. If you want to read up what happened then, LWN has good coverage.

Like last year, I will be running the Audio conference track of LPC. Audio infrastructure on Linux is still heavily fragmented. Pro, desktop and embedded worlds are very seperate. While we have quite good driver support the user experience is far from perfect, mostly because our infrastructure is so balkanized. Join us at the LPC and help to fix this! If you are doing audio infrastructure work on Linux, make sure to attend and submit a paper!

Sign up soon! Send in your paper quickly!

See you in Portland!

If you live in Berlin and are a GNOMEr of some kind then please feel invited top drop by tomorrow (Fri 29) at 4 pm at the Prater Biergarten (Weather permitting outside, otherwise inside). We'll have a little GNOME get-together. For now, we know that at least the Openismus Berlin folks will be there, as will I and presumably one special guest from Finland, and whoever else wants to attend.

Hope to see you tomorrow!

I learned so much when I read this interview. And so will you!

In my on-going series Writing Better Audio Applications for Linux, here's another installment: a little explanation how fragments/periods and buffer sizes should be chosen when doing audio playback with traditional audio APIs such as ALSA and OSS. This originates from some emails I exchanged with the Ekiga folks. In the last weeks I kept copying this explanation to various other folks. I guess it would make sense to post this on my blog here too to reach a wider audience. So here it is, mostly unedited:

Yes. You shouldn't misuse the fragments logic of sound devices. It's
like this:

   The latency is defined by the buffer size.
   The wakeup interval is defined by the fragment size.

The buffer fill level will oscillate between 'full buffer' and 'full
buffer minus 1x fragment size minus OS scheduling latency'. Setting
smaller fragment sizes will increase the CPU load and decrease battery
time since you force the CPU to wake up more often. OTOH it increases
drop out safety, since you fill up playback buffer earlier. Choosing
the fragment size is hence something which you should do balancing out
your needs between power consumption and drop-out safety. With modern
processors and a good OS scheduler like the Linux one setting the
fragment size to anything other than half the buffer size does not
make much sense.

Your [Ekiga's ptlib driver that is] ALSA output is configured
to set the the fragment size to the size of your codec audio
frames. And that's a bad idea. Because the codec frame size has not
been chosen based on power consumption or drop-out safety
reasoning. It has been chosen by the codec designers based on
different reasoning, such as latency.

You probably configured your backend this ways because the ALSA
library docs say that it is recommended to write to the sound card in
multiples of the fragment size. However deducing from this that you
hence should configure the fragment size to the codec frame size is
wrong!

The best way to implement playback these days for ALSA is to write as
much as snd_pcm_avail() tells you to each time you wake up due to
POLLOUT on the sound card. If that is not a multiple of your codec
frame size then you need to buffer the the remainder of the decoded
data yourself in system memory.

The ALSA fragment size you should normally set as large as possible
given your latency constraints but that you have at least two
fragments in your buffer size.

I hope this explains a bit how frag_size/buffer_size should be
chosen. If you have questions, just ask.

(Oh, ALSA uses the term 'period' for what I call 'fragment'
above. It's synonymous)

Andre Klapper just informed me that GNOME is now officially esound-free: all modules have been ported over to libcanberra for event sounds or GStreamer/PulseAudio for everything else. It's time to celebrate!

It's an end of an era. The oldest version of esound in GNOME CVS is 0.2.1, commited on May 11th 1998. It has been shipped with every GNOME release since 1.0 back in 1999. (esound outside of GNOME dates even further back, probably some time in the year 1997 or so). After almost 11 years in GNOME it's all over now. Oh, those were the good times.

If you maintain a module that is not part of GNOME that still uses esound, hurry and update yours as well!

Eduardo Lima just added a couple of more videos from one of the best conferences in existence to the OpenBOSSA channel at blip.tv. Humbly as I am I'd like to ask everyone who is interested in real-time and/or audio/video/animation programming to have a peek at this particular one.

That's all.

The JACK folks and I have agreed on a little specification for device reservation that allows clean hand-over of audio device access from PulseAudio to JACK and back. The specification is generic enough to allow locking/hand-over of other device types as well, not just audio cards. So, in case someone needs to implement a similar kind of locking/handover for any kind of resource here's some prior art you can base your work on. Given that HAL is supposed to go away pretty soon this might be an option for a replacement for HAL's current device locking. The logic is as simple as it can get. Whoever owns a certain service name on the D-Bus session bus owns the device access. For further details, read the spec.

There's even a reference implementation available, which both JACK2 and PulseAudio have now integrated.

Also known as PAX SOUND SERVERIS.

#nocomments y

So I wanted to hack proper channel mapping query support into libsndfile, something I have had on my TODO list for years. The first step was to find the source code repository for it. That was easy. Alas the VCS used is bzr. There are some very vocal folks on the Internet who claim that the bzr user interface is stupendously easy to use in contrast to git which apparantly is the very definition of complexity. And if it is stated on the Internet it must be true. I think I mastered git quite well, so yeah, checking out the sources with bzr can't be that difficult for my limited brain capacity.

So let's do what Erik suggests for checking out the sources:

$ bzr get http://www.mega-nerd.com/Bzr/libsndfile-pub/

Calling this I get a nice percentage counter that starts at 0% and ends at, ... uh, 0%. That gives me a real feeling of progress. It takes a while, and then I get an error:

bzr: ERROR: Not a branch: "http://www.mega-nerd.com/Bzr/libsndfile-pub/".

Now that's a useful error message. They even include an all-caps word! I guess that error message is right -- it's not a branch, it is a repository. Or is it not?

So what do we do about this? Maybe get is not actually the right verb. Let's try to play around a bit. Let's use the verb I use to get sources with in git:

$ bzr clone http://www.mega-nerd.com/Bzr/libsndfile-pub/

Hmm, this results in exactly same 0% to 0% progress counter, and the same useless error message.

Now I remember that bzr is actually more inspired by Subversion's UI than by git's, so let's try it the SVN way.

$ bzr checkout http://www.mega-nerd.com/Bzr/libsndfile-pub/

Hmm, and of course, I get exactly the same results again. A counter that counts from 0% to 0% and the same useless error message.

Ok, maybe that error is bzr's standard reply? Let's check this out:

$ bzr waldo http://www.mega-nerd.com/Bzr/libsndfile-pub/
bzr: ERROR: unknown command "waldo"

Apparently not. bzr actually knows more than one error message.

Ok, I admit doing this by trial-and-error is a rather lame approach. RTFM! So let's try this.

$ man bzr-get
No manual entry for bzr-get

Ouch. No man page? How awesome. Ah, wait, maybe they have only a single unreadable mega man page for everything. Let's try this:

$ man bzr

Wow, this actually worked. Seems to list all commands. Now let's look for the help on bzr get:

/bzr get
Pattern not found  (press RETURN)

Hmm, no documentation for their most important command? That's weird! Ok, let's try it again with our git vocabulary:

/bzr clone
Pattern not found  (press RETURN)

Ok, this not funny anymore. Apparently the verbs are listed in alphabetical order. So let's browse to the letter g as in get. However it doesn't exist. There's bzr export, and then the next entry is bzr help (Oh, irony!) -- but no get in-between.

Ok, enough of this shit. Maybe the message wants to tell us that the repo actually doesn't exist (even though it confusingly calls it a "branch"). Let's go back to the original page at Erik's site and read things again. Aha, the "main archive archive can be found at (yes, the directory looks empty, but it isn't): http://www.mega-nerd.com/Bzr/libsndfile-pub/". Hmm, indeed -- that URL looks very empty when it is accessed. How weird though that in bzr a repo is an empty directory!

And at this point I gave up and downloaded the tarball to make my patches against. I have still not managed to check out the sources from the repo. Somehow I get the feeling the actual repo really isn't available anymore under that address.

So why am I blogging about this? Not so much to start another flamefest, to nourish the fanboys, nor because it is so much fun to bash other people's work or simply to piss people off. It's more for two reasons:

Firstly, simply to make the point that folks can claim a thousand times that git's UI sucks and bzr's UI is awesome. It's simply not true. From what I experienced it is not the tiniest bit better. The error messages useless, the documentation incomplete, the interfaces surprising and exactly as redundant as git's. The only effective difference I noticed is that it takes a bit longer to show those error messages with bzr -- the Python tax. To summarize this more positively: git excels as much as bzr does. Both' documentation, their error messages and their user interface are the best in their class. And they have all the best chances for future improvement.

And the second reason of course is that I'd still like to know what the correct way to get the sources is. But for that I should probably ask Erik himself.

Here's a little a little tool I wrote that automatically generates copyright headers for source files in a git repository based on the git history.

Run it like this:

~/projects/pulseaudio$ copyright.py src/pulsecore/sink.c src/pulsecore/core-util.c

And it will give you this:

File: src/pulsecore/sink.c
	Copyright 2004, 2006-2009 Lennart Poettering
	Copyright 2006-2007 Pierre Ossman
	Copyright 2008-2009 Marc-Andre Lureau
File: src/pulsecore/core-util.c
	Copyright 2004, 2006-2009 Lennart Poettering
	Copyright 2006-2007 Pierre Ossman
	Copyright 2008 Stelian Ionescu
	Copyright 2009 Jared D. McNeill
	Copyright 2009 Marc-Andre Lureau

This little script could use love from a friendly soul to make it crawl entire source trees and patch in appropriate copyright headers. Anyone up for it?

So you are hacking an audio application and the audio data you are generating might eventually end up in PulseAudio before it is played. If that's the case then please make sure to read this!

Here's the quick summary for Gtk+ developers:

PulseAudio can enforce all kinds of policy on sounds. For example, starting in 0.9.15, we will automatically pause your media player while a phone call is going on. To implement this we however need to know what the stream you are sending to PulseAudio should be categorized as: is it music? Is it a movie? Is it game sounds? Is it a phone call stream?

Also, PulseAudio would like to show a nice icon and an application name next to each stream in the volume control. That requires it to be able to deduce this data from the stream.

And here's where you come into the game: please add three lines like the following next to the beginning of your main() function to your Gtk+ application:

...
g_set_application_name(_("Totem Movie Player"));
gtk_window_set_default_icon_name("totem");
g_setenv("PULSE_PROP_media.role", "video", TRUE);
...

If you do this then the PulseAudio client libraries will be able to figure out the rest for you.

There is more meta information (aka "properties") you can set for your application or for your streams that is useful to PulseAudio. In case you want to know more about them or you are looking for equivalent code to the above example for non-Gtk+ applications, make sure to read the mentioned page.

Thank you!

Oh, and even if your app doesn't do audio, calling g_set_application_name() and gtk_window_set_default_icon_name() is always a good idea!