[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

I was fortunate enough to be invited by Scott Reeves to speak about PulseAudio and specifically the KDE Integration work recently undertook. Scott works mostly on the SLED side of things (Enterprise Desktop) and PulseAudio falls within his remit. I'm pleased to say that the next version of OpenSuse's KDE flavour will follow the lead of Mandriva, Fedora and, most recently Kubuntu, and default to use PulseAudio under KDE. This is IMO a great step forward and will help continue the acceptance and appreciation of PulseAudio and I'm very happy to have played a part in making that possible.

Our talk itself went very well and seemed to be well received. It was also a pleasant surprise to finally meet both Takashi Iwai and Lennart Poettering who attended my talk and generally milled around. I've managed to miss meeting Lennart at various events over the years and while we've worked quite closely on PulseAudio in the past (to the extent he trusts me enough with managing the PA project while he works on the systemd project), it was nice to actually "talk" about PulseAudio! The subsequent BoF (Birds of a Feather) session on systemd was also very interesting (even if there was a little bit of a sticking point on defining preload vs. readahead which IMO was really labouring semantics to a degree and prevented getting to the more interesting stuff!). Takashi is another one of the few people who work on Linux Audio and it was nice to chat to him after exchanging several emails over the years on the ALSA mailing list.

The rest of the conference was also interesting. As someone who sits rather on the fence between KDE and Gnome it was interesting to see the developments in Gnome 3 demonstrated. There were various other titbits of interesting things too, but I wont bore the world with the details!

On the Saturday, I took the tram to the south of Nürmberg and visited their New Museum of Art and Design. It was very enjoyable. Almost deserted, which made it a rather nice experience, but also sad to see such a place under appreciated. Still it was quite early when I went, so maybe it hots up in the afternoon! My favourite photographs were by Gabriele Basilico and depicted a series of chairs with interesting seats: lattice, round holes, metal bars etc. and then accompanying photographs of a bottom that had clearly been sitting in said chair for a while. That quite tickled me An installation peace by Jeppe Hein was also very smart. Using light, mirrors and sensors to create interactive "rooms", including and empty one that just set off an alarm when you stepped into it (no doubt just to make people jump!). I then walked up through the centre checking out the churches (which would be a lot more interesting if they didn't have all that religious stuff inside them!) and the castle. A thoroughly pleasant day out!

When it was time to return home, my only regret was that I didn't get a chance to say goodbye to Scott, so as luck would have it I bumped into him at the airport in the queue going through security. It turned out he was on my flight to Amsterdam anyway so we were able to have a little blether on the way there.

What came as even more of a coincidence was the fact that I bumped into my mate Dom who happened to sit in front of me on the connecting flight to Edinburgh! He'd just been off climbing Kilimanjaro, which is arguably slightly more interesting than my week but he got his phone stolen at the "security" check in the airport (and the subsequent delay that it caused actually meant he was on my flight rather than an earlier one) so that evened things up!

But all in all, thanks to Novell, OpenSuse and Scott for inviting me along!

So apologies for that. I know some distro maintainers look at the Mandriva packages subversion for patches etc. so I'm sure some folks will have these fixes already, but it was a mistake not to push them upstream sooner.

Anyway, fixes are pushed to upstream master and stable-queue and will be part of the (hopefully) upcoming bugfix release.

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!

Quick screenie before a more detailed description:

What does this mean?

Well it means you will typically get three or four tabs in KMix that represent (in order), "Playback Devices", "Capture Devices", "Playback Stream" and "Capture Streams".

All the physical (and virtual) cards' output "sinks" will appear under "Playback Devices". I'm sure the names are pretty obvious so I wont explain further!

The functionality is close to pavucontrol, but with three important exceptions:

1. There is no equiv of the "Configuration" tab to change "Profile" for a given card.
2. There is no way to change "Ports" for a given Sink/Source (not all sound hardware supports this and it is intended to make this automatic in some cases - i.e. Headphone Jack Sensing - once it becomes reliable upstream in ALSA, but sometimes it will still be user choice (e.g. Amplified vs. Non-Amplified))
3. There is no way to move an given application from one output to another.

For 1 and 2 I intend to (eventually) provide a KCM to go alongside the Multimedia tab. For 3 you can move "categories" of applications to different devices via the Phonon settings in System Settings -> Multimedia already thanks to my previous patches.

Where can I get it?

It's already in Mandriva Cooker or you can grab it from my Git repo here: http://colin.guthr.ie/git/kdemultimedia/log/?h=pulse

The master branch is upstream svn. The pulse branch is my changes. Do a clone then issue:

 git diff master..pulse >mypatch.patch

or just build it directly.

Hopefully it'll be committed to trunk soon and if all goes well it can be easily backported to Mandriva 2010 too.

Caveats

Every time a new slider appears it is added to the "Shortcuts" system. This is OK for hardware devices, but for every application it can get a bit much.... I'll try and find a way to disable this (see "What's Left" below).

PulseAudio supports a pretty crazy limit on the number of channels a device or stream can have. Kmix only has support for a fairly standard set of elements. In come cases not all channels of a given device/stream may be shown in kmix due to this limitation. Stereo -> 5.1 setups should work fine tho'.

You Suck, I use PA but I want a Real Man's ALSA mixer!

Whatever floats your boat baby!

 $  KMIX_PULSEAUDIO_DISABLE=1 kmix

Knock yourself out!

What's Left?

I have two remaining issues that I do not think are show stoppers:

1. Everytime a new device shows up a new Global Shortcut dialog appears. I don't think this is any different to ALSA but as I now have per-app volume control, this dialog is also shown everytime a new application plays sound. It only happens the first time a given application plays a sound, but it could still be considered annoying by some.
2. If there are no capture streams running at startup the tab for that will never be displayed - likewise if the stream restore module in PA is not loaded (unlikely) the "Playback Streams" tab will never be displayed.
3. There are various things that could be more efficient (e.g. refreshing the GUI for a new device or application current redraws all tabs, not just the one that has changed when a new application appears or disappears)
4. Make KMix dumber! KMix is pretty clever and it tries to do some smart things like saving and restoring volume for you. But when PA is used, it knows better, so I need to ensure that KMix does not do any saving/restoring of actual volume values.
5. Use application icons for per-application streams. Just for eye candy, it would be nice to use the applications own icon in the GUI.

There were a few teething problems due to some last minute merges I did (which I clearly didn't test properly - my bad) and which I then went on to mis-interpret which led me to commit two rather silly things in phonon (a revert and then a revert of that revert!). What can I say... I need more caffeine obviously!

Update: PulseAudio 0.9.21 is now out and has all the necessary fixes to make the below patches unnecessary.

The slightly annoying news is that the support needed for this to work is not yet in a released version of PA. I do however have a simple patch for you here, that distro packagers are welcome to stealliberate from the Mandriva SVN. If you do this, you'll also need to apply this minor patch to phonon:

diff --git a/phonon/CMakeLists.txt b/phonon/CMakeLists.txt
index c5ce57a..50a3851 100644
--- a/phonon/CMakeLists.txt
+++ b/phonon/CMakeLists.txt
@@ -8,7 +8,6 @@ endif (PHONON_BUILD_EXAMPLES)

 add_subdirectory(experimental)

-set(PULSEAUDIO_MINIMUM_VERSION "0.9.21")
 macro_optional_find_package(PulseAudio)
 macro_log_feature(PULSEAUDIO_FOUND "PulseAudio" "A cross-platform, networked sound server." "http://www.pulseaudio.org" FALSE "" "Allows audio playback via the PulseAudio soundserver when it is running")
 macro_optional_find_package(GLIB2)

Just so that it recognises your PA build.

There don't seem to be any specific bugs yet, although I am dealing with something relating to streams going AWOL with Xine, but I'm not sure the problem is in this code. Further testing and feedback is much appreciated. Feel free to report problems to me directly or assign bugs to my kde (at) <this domain> account in b.k.o.

Have fun!

This article follows on from my previous articles here and here. If you've not read them, then it would make sense to give them a quick glance (also as this was composed on my phone while on a flight, please forgive me any silly spelling errors I didn't spot when reviewing it!!)

First of all it's probably worth explaining what happens and what the phonon backend itself needs to be aware of and how it can interoperate with pulse.

So when libphonon is used in an application, a connection to PulseAudio will be attempted. If that connection fails everything will work as currently and nothing much changes. If the connection succeeds, we establish if "module-device-manager" is loaded. This is a module specifically written to implement the routing policy (an ordered priority list of devices for each category of sound produced - e.g. Notifications, Music or Video). If this module is not detected we offer a reduced/cut-down PulseAudio integration where the user will only see a single, virtual "PulseAudio" sound "device" listed in the KDE configuration system's multimedia section. If m-d-m is detected however, users will get the full rich experience. All of the devices ever seen by PulseAudio (I.e. Built in sound cards, PCI devices, USB speakers and headsets, Bluetooth devices and Apple Airtunes devices etc.) will be listed. If the device is not currently available, it will be shown greyed out as expected and you can of course reorder them to suit your own preferences.

So all that is well and good from a user perspective but "how does it work internally?" I hear you scream!

The Nitty Gritty

When m-d-m is used the device preference order is not actually stored in phonon itself as is the case when PulseAudio is not used, it is instead passed across to PulseAudio which takes over responsibility for keeping this priority list up to date. Why do it this way? Well while the preferences stored in KDE work fine for phonon apps they do not cover any non-phonon ones (which still make up the vast majority of sound producing applications on Linux). As someone involved with sound on Linux I've often been asked by confused users why their preferences are not honoured in e.g. Audacious or other non-phonon apps. As PulseAudio is integrated lower down the sound stack than phonon, ensuring it knows your device order preferences also ensures that it can route your audio appropriately according to your preferences for all apps! A clear bonus

Now as you may know phonon has it's own API calls to move streams to specific devices. This is something also handled in PulseAudio so it makes sense to simply wrap up the phonon API around these PA call which is exactly what I do! However, there is a complication. As phonon has pluggable backends, we don't actually speak to pulse directly to do the sound output (our connection to the PulseAudio daemon is only for querying and control purposes) so we don't know which stream is ours when the audio is actually playing. To get around this obscurity introduced by the pluggable backends, we take advantage of a facility in PulseAudio to attach arbitrary metadata to our streams by way of setting special environment variables. When phonon is instructed to start outputting audio, we set both the PulseAudio "media.role" property (this is the equivalent of the Phonon Categories system and we happily have an easy 1:1 mapping) and we generate a GUID for our stream and assign it as the "phonon.streamid" property. Our control connection sees all audio streams played in PulseAudio and can use this streamid to map back the PulseAudio streams to the phonon streams. This then allows us to process the stream move requests! It's a bit of a round about road to get this capability but it is the only way we can skirt around the obscurity provided by a pluggable backend system in a general way (the opaque interfaces provided by e.g. Xine, GStreamer and other backends would not expose this info directly anyway).

"But wait!" I hear those of you paying close attention scream. "Didn't you say above that PulseAudio will do the routing for us according to our preferences? Why not let it do that for phonon streams as well as non-phonon streams and forget about the whole GUID thing?" Well, if truth be told, I did start off doing it this way but it had two major issues. The first was the "Test" button not working properly - it always resulted in the highest priority device being used, no the one the user had selected! Not really ideal and more than a little confusing I'm sure you'll agree! The second problem related to visual feedback. When you reorder your devices or plug in a device of higher priority when sound is currently playing, phonon will visually inform the user of the device change. Handing over wholesale to PulseAudio meant that this feedback was lost. Again this is certainly not what I'd call seamless integration!

So at present the stream will be routed to the correct device by PulseAudio and then Phonon will also issue a move command which should in most cases be a NOOP. Likewise when devices are hotplugged (or unplugged!) PulseAudio will route them correctly and phonon will follow this up with a specific move request which will again end up being a NOOP. While this may seem pointless it does allow for the phonon API to be use properly (as needed by the test button) and give visual feedback)

Backends

So what does it mean for a backend? Well the backend needs to be somewhat aware of PulseAudio. Thankfully this is pretty trivial thanks to the PulseSupport class I've written. The backend should ask PulseSupport if pulse is detected if so it should check for and enable it's own PulseAudio output system. If this cannot be fond or activated it can tell PulseSupport that it's a no go and everything should fall back to how things work without any PulseAudio support. There are a couple other bits and bobs that a backend needs to do to work fully but that's the bulk of it.

So I hope I've provided a good and in-depth overview of how this support works. Please keep any comments on topic. If you want to post comments about PA in general, please do so on (and after reading!) this article.

This support is included in the upcoming Mandriva 2010.0 Release which will be hitting the streets very soon.

If you have kept the same install for several distro releases, with just upgrades rather than fresh installs, then chances are you will have quite a few old libraries installed on your system. The easiest way to purge all these no longer needed libraries is to compare the packages that are available via urpmi and what packages are installed. If you have packages that are installed but that are not available to install, chances are it's an orphan.

So I wrote a very simple script that compares the two outputs and I include it here so you can do your own spring cleaning! This is very similar to the yum orphan finding tool on Fedora (well I last tried it a while back, so it may have moved on since then!).

Hope it's useful to some people:

#!/bin/bash

TMP_AVAILABLE=$(mktemp /tmp/orphans.XXXXXX)
TMP_INSTALLED=$(mktemp /tmp/orphans.XXXXXX)
urpmq -fa . | sort -u >$TMP_AVAILABLE
rpm -qa --nosignature --nodigest --qf '%{name}-%{version}-%{release}.%{arch}\n' | sort -u >$TMP_INSTALLED

diff -u $TMP_AVAILABLE $TMP_INSTALLED | grep "^+[^+]" | cut -b2-

rm -f $TMP_AVAILABLE $TMP_INSTALLED