It's been a long time coming and I'm very glad this is finally out of the door and I look forward to a much more streamlined release process in the future.

There are too many people to thank but in particular I'd like to thank Arun Raghavan, Tanu Kaskinen, David Henningsson, Maarten Bosmans, Daniel Mack, Jason Newton, Jyri Sarha, Lu Guanqun, Luiz Augusto von Dentz, Marc-André Lureau, Pierre-Louis Bossart, Siarhei Siamashka and of course Lennart Poettering.

There is more info over on the announce mail, so give it a read and also see our release notes.

Obviously there is still a huge amount to be done, both in the daemon itself, improving documentation and improving integration into the desktop environment itself. Any help is gratefully received!

So stay tuned for future improvements! And speaking of staying tuned, I'd also like to announce Planet PulseAudio. This is an aggregated feed of posts about PulseAudio. If you have a blog and write about PA, please get in touch and we can add your feed. The design is heavily borrowed from Planet GNOME so it should be familiar for some readers.

Packages are already available for Mageia Cauldron and backports for Mageia 1 will be available sometime soon. Hopefully someone will update the packages in Mandriva as I'm not actively doing stuff over there these days.

Happy listening!

PS I'm sure there will be a brown bag moment to come with a 1.0 release, but fingers crossed.... :p

Well as I'm now mostly running Mageia, I decided it was worth posting a follow up article. Read on if you're interested in the nitty gritty of how such a system works.

So most of the details in that previous article still stand true, although thankfully it's now much simpler and requires very little in the way of patching of system files etc.

The Mandriva and Mageia rc.sysinit files both support the "early local" script (like rc.local, but executed much earlier in the boot process) which allows us to inject the necessary tweaks.

What are those necessary tweaks? Well primarily it's for setting up some tmpfs files and some unionfs or aufs2 mounts. The standard system init does actually do quite a lot towards getting this working automatically, but I've never had much success with that and there are a still a few things missing (related to dbus) so I prefer to keep things simple!

When I first upgraded my chroot to Mageia, the first hurdle was that mkinitrd-net was not available for Mageia. Thankfully I already had this installed from Mandriva days and the package still works fine. I'll make sure we import this package into Mageia so this won't be a problem ongoing. The second problem was that when booting with the latest kernel, the kernel panicked quite quickly relating to unionfs. It seems unionfs+nfs don't really agree that much. So I reverted back to the old Mandriva kernel which worked fine. So with a little research, I found out that aufs2 is basically replacing unionfs these days. With a couple of checks I was able to add aufs2 support to my rc.early.local script easily enough. This allowed the boot to work without any issues.

In actual fact, even with unionfs and the old kernel, things didn't work perfectly and relied on various tmpfs mounts done by the standard rc.sysinit. Without these, I found various issues relating to kernel panics and general slow performance. With aufs2 these problems don't seem to exist anymore and I can bypass these mounts for a simpler mount setup which is all rather nice.

So once things booted the second problem turned out to be related to keyboard support... I can't quite remember what this was, but I suspect it just related to me not having evdev installed... my memory is sketchy tho'. It certainly wasn't a big problem. What was a big problem was that my user had no rights to various hardware devices. I quickly realised that this related to console kit not marking my login (which was via the autologin package) as "active". This took a little more sleuthing but I finally realised this was down to not bringing the autologin package up to date with the recent(ish) changes in console kit, namely the pam ck connector. With a little bit of patching of the /etc/pam.d/autologin file, I was up and running again! I've reported this to the Mageia devel list. Hopefully someone who knows this stuff better than me can comment and we can push an update soon now the updates and QA processes are in place.

So without further ado, here is the contents of my rc.early.local. The comments should mean the file kinda speaks for itself.

#!/bin/bash

# Fake an eth0 configuration
cat >/etc/sysconfig/network-scripts/ifcfg-eth0 < DEVICE=eth0
ONBOOT=yes
NOZEROCONF=yes
EOF


If anyone has any suggestions for improvements or wants to discuss any of the bits in detail, just leave a comment!

While last year it felt like I was the lone voice singing the praises of PulseAudio (although there were a few supporters!), but this year it feels like everything has gone 180° with pretty much everyone on board! This is a great result for me personally as I've been pretty much the only person working on KDE+PulseAudio integration, so I was very pleased to get this feedback. It's good to know that the hard work and effort you put in is appreciated. It's all too often that the people who appreciate your work are the silent majority (if you do a really good job, they don't know you've done anything as things Just Work™), while the vocal minority are quick to shout and judge and generally flame.

So I was off to an lovely start and I got down to hacking. What did I do this year? Well I continued some work on the interface I made last year called "Speaker Setup". I realised just a short while ago that there was no interface in KDE to be able to change the Source Ports (i.e. pick Mic vs. Line In on your laptop) so I set about extending speaker setup to cope with this. I added a Mic VU meter for good measure (mainly to use up the space with something vaguely useful!). I would ultimately like to do more with this UI but this would need more changes in PulseAudio itself (come listen to my talk in Berlin at the Desktop Summit if you want to know more about this!).

As well as this, I did some tweaks in Phonon to tidy some things up. Various bits and bobs within Phonon and the KCM had bit rotted a little, so minor tweaking saw that all brought up to speed.

I also spent some time hacking on PulseAudio itself, improving some earlier work related to adding Source Output volume controls to PA to take on peer review comments (for those of you unaware, this is capture stream volume control - PA has long supported "per-application" volume control but this only actually applied to outputs. It's not really very common for users to record multiple streams at the same time so support for per-capture stream volumes was never introduced. Now that PA supports Flat Volumes (a feature that always tries to use the hardware volume whenever possible to get the most efficient volume adjustment path), it makes sense to use this for inputs too. It also establishes a degree of symmetry to the API which has always felt a little weird in the past - especially if you are developing a VoIP app (the guys from Skype were a little confused about this disparity for example)). I also spent some time making some minor improvements to pavucontol (shh, don't tell the KDE guys but this is a GTK app!) as this is still my main debug tool when hacking on PA (I mainly improved it to deal more gracefully with errors - like when PA itself crashes and leaves behind the X11 root window's PULSE_SERVER property which results in an invalid argument error from the context with the result that the automatic reconnect mode doesn't work! - but also added some simple keyboard shortcuts that I generally miss when switching windows quickly). I also added support for Source Output volumes to KMix, but this will stay in my private branch until I've committed the PA code as the version check will currently match git master code even if it doesn't yet have the support needed!

I also started to look at Arun and Pierre's awesome work to support passthrough. As there is no reliable way to query receivers for the encodings they support (AC3, DTS etc.) we have to provide a way for users to specify this manually. I worked to rejig how PA stores various bits of information in internal databases to allow for arbitrary lengths of data to be stored rather than the fixed size blobs supported currently. This will pave the way to adding a protocol extension to set the formats for which support will have to be added to the Speaker Setup GUI somehow...

In addition, I also looked at VLC's PulseAudio output layer. I've known for a while that it's kind of lacking and Rémi from upstream VLC has become rather exasperated about the lack of good documentation we provide. I fully appreciate our docs are lacking (some mails on our mailing list today highlight that internal docs for module development are also severely lacking), but I was able to use what was out there to add what I think is quite robust support to VLC. As VLC is used as a Phonon backend by some distros, I felt this was an important task to work on during this KDE sprint.

All in all it was a pleasure to stay here again and meet some now familiar as well as some new people (especially Bart and Trever who are big PA fans!) I look forward to seeing several of them again in Berlin and hopefully next year here in Randa too!

I've not had nearly as much time to contribute as much as I would have liked to this release, due to various personal, work and upstream project commitments, but I know my good friends and colleagues have done a stellar job (and I've helped out when I can).

I should say that this shouldn't be expected as a ground breaking release. We're not using Gnome 3 or Systemd yet (both will most likely come in Mageia 2) as this release more signifies the establishing of all the various infrastructure needed to create a distro (build cluster, community management, mirror management etc.) especially the proper cleaning and rebuilding of all of the Mandriva packages thought to be essential or vaguely useful. This was a momentous task and one that I think has been achieved in good time.

Onwards and upwards! (to 2!)

I've included my abstract below just in case you are interested.

PulseAudio integration has come a long way. The times when detractors derided it for crashing or simply not working are mostly in the past (there are always exceptions!) and the various distributions now have solid integration and configuration options available. ALSA has also come a long way to support the timer-based scheduling that PulseAudio uses by default.

Today, a major hurdle is UI and Desktop Environment integration. In this talk I intend to look at the current UIs in both GNOME and KDE and the kind of interfaces that are missing and are still needed and what options still need to be exposed from the underlying ALSA level. I'll look at the routing logic chosen under the (more exposed) KDE and the (more minimal) GNOME interfaces and how we support that at the PA level. I'll also look at how we should be configuring some of the more advanced features of PA in a way that can fit in neatly to the DE with their own, native UI.

[colin@jimmy ~]$ uname -a
Linux jimmy 2.6.37-desktop-3.mga #1 SMP Tue Jan 25 14:16:42 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
[colin@jimmy ~]$ cat /etc/mageia-release
Mageia release 1 (Cauldron) for x86_64

Yay! Now I should be able to step up the pace of my contributions as I find it much easier and more natural to work and test as I go on my own computer rather than in a virtualised environment.

Personally I upgraded my computer from Cooker which I had frozen in a pre-rpm5 state, diligently not doing any updates despite wanting several newer packages (esp the latest Firefox 4 beta). The upgrade itself went fairly smoothly, but had some hiccups. These were mostly solved when I realised I still had a bunch of stuff in my urpmi skip.list and cleaned it out (I had various rpm things in there to prevent rpm5 being accidentally installed - I'm sure it'll be good eventually, but I'll hold off for a little while ).

So now I can update my computer again, the magic can return! Mageia has arrived!!!

While the "a52" plugin is part of the official ALSA plugins source, some distros do not compile it by default. It's available in Mandriva out of the box, but on Ubuntu for example you'll need to compile it yourself or find someone who provides a custom build for you (feel free to suggest a PPA in the comments below). Someone did tell me about pretty good instructions about building the plugin yourself.

So after building the plugin all you need to do is add a snippet of ALSA configuration to setup the a52 plugin with a named PCM that PulseAudio checks for and then everything should work automatically.

Here is the snippet. I'd recommend adding it to your ~/.asoundrc file (just create it if it doesn't exist; ~/ is just a shortcut to your home directory).

pcm.a52 {
  @args [CARD]
  @args.CARD {
    type string
  }
  type rate
  slave {
    pcm {
      type a52
      bitrate 448
      channels 6
      card $CARD
    }
    rate 48000 #required somehow, otherwise nothing happens in PulseAudio
  }
}

(just as a note, the previously linked article has an error when is suggests using echo to add this to your ~/.asoundrc as it doesn't double escape the $CARD)

Once this is in place, then PulseAudio will automatically probe it and provide you the option of selecting a 5.1 Digitial Output profile. You can use pavucontrol's Configuration tab to pick your profile (or gnome-volume-control or the Speaker Setup tab in KDE).

One other thing you may have to do to get this working properly is change the default sample rate used by PA to be 48kHz. To do this, just edit daemon.conf in either /etc/pulse or ~/.pulse and include the line:

default-sample-rate = 48000

What about Passthrough?

At present Passthrough support isn't available in the latest released version of PA (it is supported in git master). Even when this is available it will be exclusive (as will any other codec support such as MP3 for Bluetooth and RAOP etc.) and as such mixing will not be available which leads to a whole set of UI and configuration problems, so in many ways using a software AC3 encoding system like the A52 plugin here has many advantages over using passthrough. Obviously there is processing and mixing overhead but for many people (myself included) this is perfectly acceptable.

One odd thing about the setup is that some applications will consider this an "Analog[ue]" output (e.g. in XBMC I have to select Analog Output and choose 5.1 speakers to get everything working correctly, but at least it works

PS, yes the title is a Wu-Tang reference

Are we ready? OK, lets being!

The shell output shown below will include my machine's name, "jimmy". My bash prompt also shows the current git branch thanks to the git-prompt package in Mandriva (you can enable it manually by following this guide). Note that for various reasons I wont go into in this guide, the development version of PA is currently 0.9.19, this is despite the current released version being 0.9.21. Its due to how the git tree is organised, and I'm hoping to fix this soon. Edit: Git master is now tracking PA 1.0 (not for any specific milestone of 1.0, but just because a 3-point version number is kinda annoying. Essential the version policy is now decided and all should be working fine now. There may still be a 0.9.23 based of the current stable-queue branch, but the next release from master will be 1.0.

May the Source Be With You

The first job is to clone our code repository. You first have to pick where you want to keep your development version. In the example below I've decided to use a folder under my home directory called "padev"

[colin@jimmy ~]$ git clone git://git.0pointer.de/pulseaudio.git padev
Cloning into padev...
remote: Counting objects: 39578, done.
remote: Compressing objects: 100% (6760/6760), done.
remote: Total 39578 (delta 32779), reused 39578 (delta 32779)
Receiving objects: 100% (39578/39578), 14.56 MiB | 1.97 MiB/s, done.
Resolving deltas: 100% (32779/32779), done.
[colin@jimmy ~]$

Now you should have a ~/padev/ folder containing the code.

Compile Time

Now it's time to compile the code, but before we do this, we have to prepare the checkout for compilation. Handily there is a script provided to make this easy for us.

[colin@jimmy ~]$ cd padev/
[colin@jimmy padev (master)]$ ./bootstrap.sh -V
+ case $(uname) in
++ uname
...
+ make clean
make: *** No rule to make target `clean'.  Stop.
[colin@jimmy padev (master)]$

There is an error about not being able to "make clean" here but you can safely ignore that.

Next we'll create a build directory. This is not mandatory, but it helps keep temporary build files etc. separate from the code in the checkout (there are special git commands to delete such files but all the same, I feel this is cleaner). After creating the build directory, we change to it and run the configure script.

[colin@jimmy padev (master)]$ mkdir build
[colin@jimmy padev (master)]$ cd build/
[colin@jimmy build (master)]$ ../configure --prefix=$(pwd)
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
...
config.status: executing po/stamp-it commands

---{ pulseaudio 0.9.19-562-g395da }---

prefix:                        /home/colin/padev/build
sysconfdir:                    ${prefix}/etc
localstatedir:                 ${prefix}/var
System Runtime Path:           ${prefix}/var/run/pulse
System State Path:             ${prefix}/var/lib/pulse
System Config Path:            ${prefix}/var/lib/pulse
Compiler:                      gcc -std=gnu99
CFLAGS:                        -g -O2 -Wall -W -Wextra -pipe -Wno-long-long -Winline -Wvla -Wno-overlength-strings -Wunsafe-loop-optimizations -Wundef -Wformat=2 -Wlogical-op -Wsign-compare -Wformat-security -Wmissing-include-dirs -Wformat-nonliteral -Wold-style-definition -Wpointer-arith -Winit-self -Wdeclaration-after-statement -Wfloat-equal -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -Wmissing-declarations -Wmissing-noreturn -Wshadow -Wendif-labels -Wcast-align -Wstrict-aliasing=2 -Wwrite-strings -Wno-unused-parameter -ffast-math -Wp,-D_FORTIFY_SOURCE=2 -fno-common -fdiagnostics-show-option -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include

Have X11:                      yes
Enable OSS Output:             yes
Enable OSS Wrapper:            yes
Enable CoreAudio:              no
Enable Alsa:                   yes
Enable Solaris:                no
Enable GLib 2.0:               yes
Enable Gtk+ 2.0:               yes
Enable GConf:                  yes
Enable Avahi:                  yes
Enable Jack:                   yes
Enable Async DNS:              yes
Enable LIRC:                   yes
Enable DBUS:                   yes
Enable HAL:                    yes
Enable udev:                   yes
Enable HAL->udev compat:       no
Enable BlueZ:                  yes
Enable TCP Wrappers:           yes
Enable libsamplerate:          yes
Enable IPv6:                   yes
Enable OpenSSL (for Airtunes): yes
Enable tdb:                    yes
Enable gdbm:                   no
Enable simple database:        no
Enable fftw:                   yes

System User:                   pulse
System Group:                  pulse
Access Group:                  pulse-access
Enable per-user EsounD socket: yes
Force preopen:                 no
Preopened modules:             all
[colin@jimmy build (master)]$

You should pay particular attention to the --prefix argument passed to configure. Rather than "installing" this version of PulseAudio, we'll just run it from the source tree. This is both quicker and saves any potential conflict with your system-installed PulseAudio packages.

You should also pay attention to the table at the end which lists the available support. In order for automatic card detection to work properly with your build, you really should ensure that udev support in particular is available. If it does not print a "yes" line in the output then you probably do not have the "udev-devel" package for your distro installed.

Let's Build

OK, so you're ready to build! But not quite. Due to an upstream bug, the translations for .desktop files are not written if the destination folder does not exist, so let's create it manually

[colin@jimmy build (master)]$ mkdir -p src/daemon
[colin@jimmy build (master)]$

OK, with all the prep work done, we really do build it.

[colin@jimmy build (master)]$ make
echo 0.9.19-562-g395da > ../.version-t && mv ../.version-t ../.version
make  all-recursive
...
file=`echo zh_TW | sed 's,.*/,,'`.gmo \
 && rm -f $file && /usr/bin/msgfmt -o $file ../../po/zh_TW.po
make[2]: Leaving directory `/home/colin/padev/build/po'
make[2]: Entering directory `/home/colin/padev/build'
make[2]: Leaving directory `/home/colin/padev/build'
make[1]: Leaving directory `/home/colin/padev/build'
[colin@jimmy build (master)]$

Now that it's built successfully we can run it, but we'll do a little bit of preparation first. As ALSA currently lacks UCM (Use Case Management) (although this is due to be added soon), PulseAudio supports a fairly robust "probing" system to determine how your sound hardware works. In order to run these probes it has to know where to look for the "mixer profile" definitions. As we are running from the build tree, we'll cheat a little and use a symlink so that our development build can find the files.

[colin@jimmy build (master)]$ mkdir -p share/pulseaudio
[colin@jimmy build (master)]$ ln -s ../../../src/modules/alsa/mixer share/pulseaudio/alsa-mixer
[colin@jimmy build (master)]$

In order to run some test tools, we also need to manually create some symlinks that are normally done as part of the install process.

[colin@jimmy build (master)]$ ln -s pacat src/paplay
[colin@jimmy build (master)]$ ln -s pacat src/parec
[colin@jimmy build (master)]$

Run, Forest, Run!

Now that things are built and some symlinks are in place, we can run our nice shiny development version. You should first ensure that the system-installed PulseAudio daemon is not running. In order to do this, you should disable autospawn by doing:

echo "autospawn=no" >> ~/.pulse/client.conf

Once this is done, you should reboot. PulseAudio will likely still start when you log in to X11 by virtue of the start-pulseaudio-x11 script that is run at login, but some systems that rely on PA autospawn may not initialise correctly (e.g. under KDE knotify and kmix may start in 'ALSA mode'. This is generally not a problem, but you should be aware of the consequences.

So if your system PA has been run, simply execute:

pulseaudio -k

To kill the currently running daemon. You can then start your development version via:

[colin@jimmy build (master)]$ src/pulseaudio -n -F src/default.pa -p $(pwd)/src/.libs/ -vvvv
W: main.c: Couldn't canonicalize binary path, cannot self execute.
I: main.c: setrlimit(RLIMIT_NICE, (31, 31)) failed: Operation not permitted
I: main.c: setrlimit(RLIMIT_RTPRIO, (9, 9)) failed: Operation not permitted
D: core-rtclock.c: Timer slack is set to 50 us.
D: core-util.c: RealtimeKit worked.
I: core-util.c: Successfully gained nice level -11.
I: main.c: This is PulseAudio 0.9.19-562-g395da
...

This will produce a lot of debug output, so you should leave that terminal running. The command line arguments are as follows: "-n" says "do not process the (system) default.pa". This is generally only needed if you have a ~/.pulse/default.pa file, but it does no harm to include it always. "-F src/default.pa" says to "process the script src/default.pa" and "-p $(pwd)/src/.libs" tells PA where to look for it's modules (i.e. from your build tree).

Note that the state files saved by PulseAudio in ~/.pulse/ folder will very likely NOT conflict with your system PA's files. This is because our development PA build does not know the right path to look for /var/lib/dbus/machine-id. Because of this, the prefix used on files will default to the host name of your machine, not the string of apparently random numbers and letters that you may see in there already. If you cross reference, the output from cat /var/lib/dbus/machine-id will show the same number as used here. We do this to ensure we can have separate preferences for different machines when your home directory is shared over e.g. NFS - the machine-id is more stable than the hostname which is why we prefer that as a prefix.

Running a Client App

So now that everything is running, you should be able to run a client application. As the build tree comes with some utilities you can run them directly from there:

[colin@jimmy build (master)]$ src/paplay -vv /usr/share/sounds/ia_ora-startup.wav
Opening a playback stream with sample specification 's16le 2ch 22050Hz' and channel map 'front-left,front-right'.
Connection established.
Stream successfully created.
Buffer metrics: maxlength=4194304, tlength=176400, prebuf=174640, minreq=1764
Using sample spec 's16le 2ch 22050Hz', channel map 'front-left,front-right'.
Connected to device alsa_output.pci-0000_00_1b.0.analog-stereo (0, not suspended).
Stream started.
Stream underrun.
Playback stream drained.: 1007045 usec.
Draining connection to server.

If, however you want to run a more advanced client application, then you need to employ a little hack to tell your system to use your development version of libpulse. This is quite trivial:

[colin@jimmy build (master)]$ export LD_LIBRARY_PATH=$(pwd)/src/.libs
[colin@jimmy build (master)]$ mplayer /path/to/your/fav.mp3
...

Easy eh? That's all you need to do to run PulseAudio from git. You can now easily try out patches, write your own modules and help contribute! Happy hacking.

Some notes on Overlinking

So, just before I sign off, I thought it was best to mention overlinking. PulseAudio itself uses a shared library that is used by both client and server. This library is "libpulsecommon-0.9.x.so". Client applications should NOT link to this file directly - instead libpulse will load it in for you. This can lead to some strange results. e.g. consider the following output:

[colin@jimmy ~]$ ldd `which paplay` | grep pulse
	libpulse.so.0 => /usr/lib64/libpulse.so.0 (0x00007f5bd9fc7000)
	libpulsecommon-0.9.21.so => /usr/lib64/libpulsecommon-0.9.21.so (0x00007f5bd9d76000)
[colin@jimmy ~]$ ldd `which mplayer` | grep pulse
	libpulse.so.0 => /usr/lib64/libpulse.so.0 (0x00007f617c1f4000)
	libpulsecommon-0.9.21.so => /usr/lib64/libpulsecommon-0.9.21.so (0x00007f6175f08000)

This looks more or less the same right? Not quite. Compare this to:

[colin@jimmy ~]$ objdump -p `which paplay` | grep pulse
  NEEDED               libpulse.so.0
  NEEDED               libpulsecommon-0.9.21.so
  required from libpulse.so.0:
[colin@jimmy ~]$ objdump -p `which mplayer` | grep pulse
  NEEDED               libpulse.so.0
  required from libpulse.so.0:

So what you can see here is that my paplay really does need both, but mplayer actually only does not directly need libpulsecommon-0.9.21.so. But what does this mean to you when running things? Well, due to the fact that PulseAudio has this kind of circular dependancy internally, we cannot use the --no-undefined or --as-needed build options. This means that the PulseAudio package is Over linked. This is why the paplay utility needs libpulsecommond-0.9.21.so directly, unlike mplayer, which does not.

So if you try and use the above guide and ultimately run the system provided paplay utility, you'll find you run into problems. This is because the system libpulsecommon-0.9.21.so will be used, not your freshly compiled version (which could have a completely different version number - e.g. libpulsecommon-0.9.19.so!).

While we don't need to run the system paplay (as we have built our own version), it's easy to forget this quirk and break things. If you want to be sure, you can place a symlink in your build folder to fool the system into loading your libpulsecommon, even when the versions don't "match". As this is an overlinking problem, there is little danger in doing this hack:

[colin@jimmy build (master)]$ ln -s libpulsecommon-0.9.19.so src/.libs/libpulsecommon-0.9.21.so
[colin@jimmy build (master)]$

This puts the necessary symlink in place to make my dev build (0.9.19) replace the system build (0.9.21). This only has effect with the LD_LIBRARY_PATH variable set, so it wont interfere with anything on your system.

Depending on your your distro packages things, the problems of overlinking may be present in more than just the paplay utility. So check this out and use objdump -p to confirm the client application you want to run is linked correctly and use the symlink hack if needed.

Those of us involved in the community surrounding Mandriva have obviously been worried that the future of our favourite distro is in doubt, so it is with great pleasure that I pass on news of the upcoming fork of Mandriva Linux: Mageia

Obviously the obligatory slashdot story only really draws comments on the choice of name. Personally, I quite like it (more so than the name "Mandriva" (which itself was a contraction of Mandrake and Conectiva - partly due to the use of the name Mandrake drawing some legal issues)). And choosing a name is no easy business: there are trademark issues to consider and domain names to secure: this can seriously limit your choice. Regardless of the practicalities, "that which we call a rose, by any other name, would smell as sweet". In other words, the name doesn't matter, what really matters is the work done and the contributions to be made to the wider Linux ecosystem.

Mandriva has long been regarded as a good participant in upstream projects, contributing to the Kernel, Graphic and Audio subsystems as well as being a very active contributor to higher level desktop environments such as KDE (and GNOME and XFCE and others too). With so many of the key contributors following this fork and contributing to Mageia, I feel this tradition will continue and grow with time.

So, as I said in one of the many "goodbye" emails I've had to write following the lay offs: The future is unwritten. Let's write it!

As well as taking part in various discussions, I was able to spend some time cooking up a UI to control the configuration of PulseAudio and the various cards attached.When adding PulseAudio support to the various parts of KDE that need it (Phonon, KMix), there was an important part of the puzzle missing: a card profile selector, and a sink/source port selector. I had always intended to include this functionality somewhere, but the KMix framework didn't really allow for it neatly (I could have created a separate dialog of course but it didn't quite feel right).

The eagle eyed readers may have seen a sneak preview of this feature when looking at the KDE-specific help page I wrote up on the PulseAudio website. So I give you this: the Speaker Setup tab in System Settings.

Speaker Setup GUI

The little icon in the middle is your user icon, so you'll see this differently unless your a weird stalker type and have set your icon to mine :s

The various drop downs allow fully control over all cards that are attached to the system. The buttons on the main pane allow you to test each speaker separately. In order to test the speakers, libcanberra is used. libcanberra is an implementation of the Free Desktop Sound Theme specification. It allows this test to be implemented with minimum hassle and I'm not personally interested in reinventing the wheel, hence the use of this library and the additional dependency.  Some people dislike using libcanberra in KDE (as was apparent from some discussions at the Multimedia Sprint), but I believe the reasons were often personal ones and not related to the usefulness of the code. If someone really wants to factor this out, they can but I have no interest in doing so and will prefer to use the existing implementation whenever possible (and this would include any future implementation I may or may not do with regards to support the Sound Theme Specification in KDE (or maybe Qt) directly)

When a 5.1 surround system is presented, the GUI is obviously a bit more advanced:

Speaker Setup GUI (5.1)

For those naysayers, I've tried my best to ensure that the compile will work fine without PulseAudio installed. It should also degrade gracefully when it is compiled with PA support, but PA is not configured to be used at runtime. The whole tab will simply not be available.

There is still one small problem left in that I don't handle disconnection/reconnection yet. This causes the GUI to crash if the PA server is stopped and restarted. This is not typically something that happens, but it's still something I will fix shortly all the same.

This code is now in trunk (r1154776) so feel free to try it out and report other bugs etc. This GUI is also included in Mandriva Cooker (I did want to include it prior to 2010.1 release, but the timing didn't work out - tho' it probably would have been OK considering the delays that cropped up in the release process). I expect this functionality to be included in any updated/backported versions of KDE for 2010.1.

For reference, in case you didn't spot it yourself, this GUI was heavily inspired by the gnome-speaker-setup utility.