If you use pthread_key_create() with a non-NULL destructor parameter (or an equivalent TLS construct) in a library/shared object then you MUST link your library wth -z nodelete (or an equivalent construct).

If you don't, then you'll have a lot of fun (like I just had) debugging segfaults in the TLS destruction logic where functions are called that might not even exist anymore in memory.

Now don't tell me I hadn't told you.

(Oh, and I hope I don't need to mention that all GObject-based libraries should link with -z nodelete anyway, for making sure the type system doesn't break.)

Ever wanted to know what's the view like being the highest person in all of Spain? -- No? Hmm, can't help you then. -- Otherwise:

That's on the summit of Pico del Teide at 3718m, on Tenerife island. Unless you leave solid ground this is as high as you can get in Spain. 163m lower it's a bit more obvious that the Teide is a volcano:

And coming down to the surrounding caldera it's even more obvious:

On a ridge next to the caldera you find the Teide Observatory:

The caldera is covered in old lava flows:

Vulcanism has created various interesting rock formations in the caldera:

Tenerife is not just about the Teide and its dusty caldera. In the north of the island you find the Anaga mountain range:

Neighboring Gran Canaria was where our little trip started and ended, right after the Gran Canaria Desktop Summit. Gran Canaria has no Teide but a very impressive landscape nonetheless:

That's the view from the Roque Nublo, the island's most famous landmark. The rock itself is visible here (on the left):

#nocomments y

As a followup to Oh Nine Fifteen here's a little overview of the changes coming with PulseAudio 0.9.16 which will be part of Fedora 12 (already in Rawhide; I think Ubuntu Karmic (?) will have it too).

A New Mixer Logic

We now try to control more than just a single ALSA mixer element for volume control. This increases the hardware volume range and granularity exposed and should also help minimizing problems by incomplete or incorrect default mixer initialization on the lower levels.

This also adds support for allowing selection of input/output ports for sound cards. This is used to expose changing between Mic vs. Line-In for input source selection and Headphones vs. Speaker for output selection (of course the list of available port is strictly dependant on what you hardware supports). The list of available ports is deliberately kept minimal.

Thanks to Bastien the newest GNOME Volume Control now exposes profile/port switching quite nicely, which he blogged about. This screenshot shows how the port (here called 'Connector') can be selected in the new dialog.

The mixer rework also allows us to handle semi-pro/pro sound cards a bit more flexibly. For example, which profiles/ports are exposed in PulseAudio or how specific mixer elements are handled can now be controlled by editing .ini file like configuration files in /usr/share/pulseaudio/alsa-mixer/. Read this mail for more information about this.

UPnP MediaServer Support

PulseAudio now integrates with Zeeshan's fabulous Rygel UPnP/DLNA MediaServer. If enabled Rygel will automatically expose all local audio devices which are managed by PulseAudio as UPnP/DLNA MediaServer items which your UPnP/DLNA MediaRenderers can now tune into. (Meaning: you can now stream audio from your PC directly to your UPnP DMP (Digital Media Player) device, such as the PS3.) Communication between Rygel and PulseAudio follows our little Media Server Spec on the GNOME Wiki. This nicely complements the RAOP (Apple Airport) support we introduced in PulseAudio 0.9.15. In one of the next versions of PulseAudio/Rygel we hope to add support for PulseAudio becoming a MediaRenderer as well. This will then not only allow you to stream from your PC to your DMP device, but also allows PulseAudio to act as "networked speaker", which can be used by any UPnP/AV/DLNA control point, such as Windows' Media Player.

Hotplug Support Improved

If you select a particular device as the default for a specific application or class of streams, then when unplugging the device PulseAudio moves the stream automatically to another audio device if one exists. New in PulseAudio 0.9.16 is that if you replug the audio device the stream will instantly be moved back, requiring no further user intervention.

Also, PulseAudio now includes some implicit rules for doing the 'right thing' when finding an audio device for an application. For example, unless configured otherwise it will now route telephony applications automatically to Bluetooth headsets if one is connected, in favour of the internal sound card of the computer.

Surround Sound Support for Event Sounds

This is more a new feature of libcanberra than of PulseAudio, but nonetheless: we now support surround for events sounds. This allows us to play full 5.1 login sounds for example, in best THX cinema fashion. We'd love to ship a 5.1 sound for login by default in sound-theme-freedesktop. We'd be very thankful if you would be willing to contribute a sound here, or two! A sound a bit less bombastic than the famous cinema THX effect would probably be a good idea though.

And then there's of course the usual batch of fixes and small improvements. A substantial number of non-user visible changes have been made as well. For example, as HAL is now obsolete PulseAudio now moved to udev for its device discovery needs. We replaced our gdbm support by support for tdb. Also, we stripped all security senstive code from PulseAudio, and ported it to use RealtimeKit instead. For the upcoming distributions that means that PulseAudio will run as real-time process by default, improving drop-out safety.

And for some extra PA eye-candy, have a look on Impulse!

#nocomments y

I hereby officially declare that I have reached my goal of world domination. Emacs 23 (apparently due today) ships with Avahi support out of the box. Obviously, one of the most natural combinations of software thinkable.

After Emacs, there's not much else I could win, or is there?

A while back I was celebrating that arrival of secure realtime scheduling for the desktop. As it appears this was a bit premature then, since (mis-)using cgroups for this turned out to be more problematic and messy than I anticipated.

As a followup I'd now like to point you to this announcement I posted to LAD yesterday, introducing RealtimeKit which should fix the problem for good. It has now entered Rawhide becoming part of the default install (by means of being a dependency of PulseAudio), and I assume the other distros are going to adopt it pretty soon, too.

Read the full announcement.

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!