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.

Sadly the GStreamer backend was plagued with some problems. I wont go into the details (primary because I don't really know them all!) but many KDE developers felt that it just wasn't appropriate and decided to write a Xine backend for Phonon instead (NOTE: This is not actually correct. Please read comment by Kevin Kofler below). This matured quickly, but it was always had it's own set of problems that resulted in many hacks to be introduced at the application level. This was very bad as it meant that those of us (Mandriva included) who stuck with and helped fix the GStreamer backend were sometimes left a little out in the cold due to these hacks. Ultimately this story has concluded with the Xine backend being more or less abandoned now, and renewed focus being put on the new VLC backend. VLC, or more accurately "VideoLAN", is a multimedia framework, very similar to GStreamer. It has a very well maintained code base and support for numerous codecs and formats. It is also totally cross platform, working with Windows, OSX and of course Linux and several embedded OSs to boot. Having a single Phonon backend with uniform capabilities and support across all platforms is very desirable, so progress with this is quite rapid and an official release of the Phonon-VLC backend will be available in a matter of weeks.

But this is all about Phonon, not Qt Multimedia or Qt Mobility. So where does this all fit in? Well, Phonon has ultimately not really been developed much by Qt. That's not to say they have totally forgotten about it. I am assured that bugs reported will be looked at, time permitting, and that patches from downstream will be tested and merged, but it's fairly clear that it will not be actively developed further and no new features will come from the Qt side. Their new babies are Qt Multimedia and Qt Mobility.

Qt Multimedia, and arguably to a larger extent, Qt Mobility has been developed with a strong focus on mobile usage. Now that Qt is owned by Nokia this is not surprising! So what was the motivation for this and how does it differ from Phonon? Well, like Phonon it also makes use of existing projects to provide the core media decode capabilities. It will continue to use GStreamer for most "linuxy" systems and others for e.g. Windows and OSX. It differs however with regards to focus. It encompasses several additional features regarding the various needs for a typical mobile environment, such as still image and video capture (think cameras on a mobile phone).

There are several other key differences too but I wouldn't like to go into detail just now (I'm not really familiar enough with either Qt MM or Qt Mob to comment in any great depth), but suffice to say that this general abandonment of innovation in Phonon in favour of a new project has left several people in the KDE multimedia community feeling rather uncertain about what to do next; which horse to back!

Here at the KDE Multimedia Sprint in Randa, Switzerland, we were lucky enough to discuss the various issues with the Qt Multimedia/Mobility guys in Brisbane, Australia via a video conference. Well it was supposed to be a video conference, but despite it being between two groups of multimedia geeks, video completely failed us (various firewall issues for one solution and the lack of admin rights at the remote end for another!), meant we had to make do with a normal phone call! Such is life! Anyway, they were kind enough to give us an overview of Qt Multimedia/Mobility and let us know their approximate roadmap.

The outcome of this meeting was more or less that KDE Multimedia focus for the short term will remain with Phonon but the Qt guys will try and be more open about their plans and try and work better with the community longer term. At present, this is an uphill struggle as the VLC project has been very active in the KDE community for the last little while and seems to fit the needs in both the short and relatively long term of KDE, albeit in a way that is not currently exposed via Phonon API. This previous lack of communication is something that will be hard to overcome, but using a Qt integrated and supported solution definitely has advantages in the future - if they really mean it this time! The fact that the code is also used on Nokia mobile platforms give a fairly good reassurance that this will indeed be the case at least!

The rather obvious question of "Why not extend Phonon?" was also raised. While it was difficult to hear exactly the responses, the general reasoning seemed to be that there were some design mistakes in Phonon that basically meant that each individual feature that needed to be added, actually needed to be done at the backend level first (for each and every backend) and then exposed out through the API. With the Qt Mobility approach, more of the core features and functionality can be implemented once, with it only reaching out the the underlying platform specific system for specific and defined operations.

We enquired about the possibility of having a single Qt Multimedia backend written for Phonon, that allowed the Phonon API to continue in use at the application level while using the underlying systems/framework provided by Qt Mobility and/or Multimedia and deprecating all other Phonon backends. This is attractive in the sense that applications to not need to change horses mid stream and can gradually move over to using a pure Qt Multimedia API if indeed that is determined to be the most desirable outcome. That said it is also unattractive in some ways too. This adds yet another layer of abstraction to a system that many people argue is a layer of abstraction too far in itself! i.e. Application uses Phonon which uses Qt Multimedia which uses GStreamer; Why not just Application uses GStreamer? (there are of course many reasons to add a layer of abstraction; cross platform support being a primary one; but two layers is arguably not the best situation, especially on mobile platforms where wasted CPU cycles really hurt). That said, it would still be an acceptable stepping stone for most people. Regardless, there was no actual commitment to this eventuality from the Qt side. It was seen as a good idea but it's likely not something that there will be time (aka budget) for developing in the near term, which is understandable.

Many of the problems with Phonon still remain however. Qt Mobility will still require the setup of different underlying support libraries on different platforms. Just as before, GStreamer will be required for it to work on Linux and downstream (distributions and, to a lesser extent, users) will need to ensure that this is all configured and working correctly. As with the original Phonon, this backend will be different on different platforms, which is not ideal for the downstream.

So in the short to medium term (e.g. the next one to two years at least), Phonon will continue to be the primary media framework on KDE, and development on the Phonon-VLC backend will be seen as the best way forward to provide a standard experience across all platforms. GStreamer as a phonon backend will also continue, although the mplayer and xine backends should be considered deprecated.

With regards to Qt Multimedia and Mobility development itself, the Qt guys will try to be more open; opening a private mailing list to more access and generally being more communicative.

Those of you who regularly read this blog will be no doubt wondering where the PulseAudio connection is. Well, from what I gather, this is a primary difference of Qt Mobility and Qt Multimedia. Qt Mutlimedia seems to use ALSA directly and thus is not ideally suited for mobile situations (PulseAudio's timer based scheduling now being pretty much universally accepted as being the preferred approach on mobile platforms). Qt Mobility does actually use PulseAudio indirectly via GStreamer, but it does not seem to do anything special with regards to the "buffer-time" or "latency-time" attributes of the pulsesink (not that pulsesink is actually referred to directly in the appropriate place anyway from what I can tell). These attributes map directly to the tlength and minreq attributes of the buffer metrics in a PulseAudio stream. These are very important when it comes to mobile environments as the general aim is to provide as high a latency as possible. Higher latency means lower power usage (and for those wondering, this does not necessarily affect A/V sync on video playback - it's just about how much data you pump into the audio buffers before sleeping until you know it'll be almost empty). For a system that deals with audio playback on a mobile device, this is very important.

Now Phonon is also similarly ignorant to these properties when using PulseAudio. The the help of folk from Intel we're going to look at increasing the defaults in Phonon when used with GStreamer pulsesink to see if higher latencies would bring benefits without any drawbacks at the application level (I don't think any of the uses of Phonon will have problems with this approach), but we'll also have to consider how best to expose this via the Phonon API to allow the application level to state more explicitly if this matters. When capture APIs become possible on Phonon this will become important. The whole question of how much thought has gone into this kind of power saving is Qt Mobility is still very much at the forefront of my mind. I hope to be able to discuss things in more depth with the developers in due course, hopefully influencing them to extend the API in a similar was as described above.

More generally, those of us in the KDE community will try to get involved with Qt Multimedia/Mobility but until such times as it is easily configurable on the Desktop or there is a Phonon backend based on it, it will be hard to get involved too deeply.

Overall I think everyone has an open mind, but with the current focus on VLC and the functionality it provides, it will be the most interesting bits for most KDE Multimedia guys for the short term.

With regards to all of the above, I hope I've made fair and levelled comments. If you feel this is not the case, please tell me so in the comments below. I will happily retract or rephrase or reconsider any point if a suitable argument is made. I do not intend to represent anyone else in the KDE community in a way they do not feel is accurate so I'll be happy to both comment and edit the article with suitable annotation if this is deemed necessary.

Edits:

1. 27th May: Clarification of my incorrect statement of when/why Xine backend was introduced. Thanks to those who pointed it out.

Firstly, it was pointed out to me that the use of a QEventLoop was not the best approach when connecting to PulseAudio from a KDE app. I used this technique in Phonon and while it seemed to work fine in testing it did trigger some problems in some unlikely places: namely this bug as reported against Okular! So I changed how the connection test to PulseAudio is run to make it blocking. This has so far appeared to fix the problems \o/

Now on to something interesting I've recently added support in Phonon for "hijacking" the volume change requests to allow them to be pushed directly to PulseAudio, totally avoiding the backend itself. In additional it is possible to listen to changes from PulseAudio and then emit the relevant Phonon signal to let applications know the volume has changed. This allows volumes changed in a PulseAudio mixer (pavucontrol and now KMix too!) to be reflected in the Application GUI (should it present it to the user).

Phonon provides it's own VolumeSlider widget that applications can use. I had to make some changes to this to avoid some complicated race conditions. As volume changes in PulseAudio are asynchronous, the change request may be followed some time later by the actual update notification. For this reason the it was not possible to use the "traditional" blockSignals(true) approach. I settled on two flags to achieve the necessary protection and it seems to be working well so far in my testing.

Then I tested Amarok and found it didn't work at all This is because Amarok has it's own volume slider widget and does not listen for any volume changes from the Phonon layer. I was able to make the necessary changes to support this without too much trouble, but in doing so I had to change the mute behaviour slightly. Due to (I'm told) legacy reasons, when the volume is muted, Amarok would also set the volume to 0. This was reflected in the GUI by the slider showing 0. While it would be possible to keep this behaviour it's not really desirable these days (the OSD always said "Volume: 0% (muted)" when muted which made it rather redundant to show the %age!) when mute is supported properly. If GUI feedback of mute status on the slider itself is desired (the image does change to a mute symbol already) then it would likely be more appropriate to change the slider colour to grey or similar (which is also how other media players - e.g. VLC represent things).

Anyway, with these issues fixed and suitable support for the feedback race conditions added to the Amarok slider code too, I've now got a rather nicely integrated solution

Here is a quick screencast I recorded to show you how all these changes: Phonon, KMix & Amarok all work together

(direct link)

As always, these latest changes are in Mandriva Cooker. The Amarok changes are not in the 2010.1 Beta 1 just recently released, but they will be part of Beta 2

I've spent quite a lot of time refining the initial support I added a few weeks back. What follows is a brief summary of the changes/improvements/bugfixes.

Firstly, some of the tabs (namely "Capture Streams" were not shown unless an application was actively capturing while kmix started... somewhat unlikely really :p This is now fixed.

Then there was a problem with Profiles. These would be created automatically when you went to the "Configure Channels..." dialog. There were actually several problems relating to profiles which ultimately lead to controls going AWOL - with no way in the GUI to see them even if the backend itself was actually aware of their presence. The concept of GUIProfiles does not really tie in too well with the concept of "Dynamic Mixers" (where controls come and go), but I think I've managed to get it all working nicely now.

And finally we come to something I said I wasn't going to do. In my last post I explained that moving streams to different devices was something best left to the System Settings -> Multimedia dialog. Lots of people commented on that post saying that individual stream moving is still needed. Well, not wanting to disappoint the public, I have now added relevant patches to enable this in KMix. The UI is not ideal yet, but you can access it via the context menu of Playback and Capture streams by right clicking on the sliders and selecting an option from the "Move" submenu.

There were several other small cosmetic fixes (like using the right icons for devices/applications in the GUI) too and a really annoying race condition due to a singleton class taking too long to start up that got fixed too.

All in all I'm rather pleased with the outcome for now. It's not perfect by any means (if the PA server dies there is not much feedback), but it's certainly a good start. Failing any massive problems with the build I've just submitted to Mandriva Cooker, I'll sync this to subversion trunk for everyone else to play with.

I had to make more changes to the core of kmix than I originally intended. I've tried to ensure I always remain backwards compatible but some subtle differences in profile loading certainly exists. I'm not sure if these are avoidable (I don't think so) so this may be a sticking point... time will tell.

Have fun

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.

Myself and the rest of the Mandriva Developers and Contributors have put in a lot of work this time round. I'm pretty happy with the PulseAudio->Phonon integration work I did for KDE which builds on our previous approaches which were not quite as functional (although did at least hide potential configuration problems from users unlike on some distros! (for which the usual "solution" was a urpme/yum remove/apt-remove pulseaudio rather than actually finding the real cause!)

Anyway, anyone looking for a change or wanting to see what other distros have to offer, I really encourage you to take it for a spin!

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

For this reason, myself and Thomas Backlund have been operating a semi-official repository of packages built for 2009.1 specifically for Intel users of 2009.1. This repository contains the latest version of:

• Kernel (currently 2.6.31.3)
• LibDRM (currently 2.4.14)
• Mesa (currently 7.6)
• Intel Driver (currently 2.9.0)

With these packages installed, performance with the intel driver should be pretty good for most people.

Of course, Mandriva 2010.0 will contain all these versions officially and should present a better OOTB experience for everyone.

The i586 repository can be added via:

urpmi.addmedia TMB-Intel-32 http://tmb.mine.nu/Mandriva/Intel-2009.1/i586/

and the x86_64 version:

urpmi.addmedia TMB-Intel-64 http://tmb.mine.nu/Mandriva/Intel-2009.1/x86_64/

More information can be found on the Mandriva Bugzilla Bug #52601

ALSA Application

So first off, an application using the ALSA API tries to open the "default" device. Assuming we've configured this default device to be the PulseAudio plugin for ALSA, it will basically act like every PulseAudio client application. We're now into the land of the PulseAudio configuration.

PulseAudio Client

PulseAudio adopts a client/server model that is very similar in principle to that of the X11 system. It is the server that actually outputs the audio and the client app that tells the server what to play. While this approach can be inefficient, resulting in the copying of audio data around, PulseAudio goes to great lengths to ensure that data copying and other latency-prone operations are kept to a minimum. In the common use case of both client and server running on the same machine, PulseAudio uses SHM (Shared Memory) to ensure that data sent from the client to server is not copied across the wire. The core of the PulseAudio server itself is "zero copy" meaning that references to the data are passed around without actually copying the data itself.

The first thing a PulseAudio client has to do is connect to a server. In order to do this, it checks various variables and configuration files to determine precisely to which server it will connect!

Initially, the PulseAudio client library looks for a PULSE_SERVER environment variable. If found, this variable can define a list of servers to which the client should connect. These servers can be specified as local UNIX sockets or DNS names/IP addresses for a TCP connection.

If this is variable does not exist or is empty, PulseAudio will then check for X11 properties on the root window. These properties are much like environment variables, but will be available remotely if you SSH to another machine with X11 forwarding. I'll speak about this more later. You can see a list of PulseAudio related properties by doing:

xprop -root | grep PULSE

The variables names used are the same as those used in the environment, so PulseAudio will look for a property called PULSE_SERVER.

Assuming it's still not got a server to connect to yet, PulseAudio will check for a default-server configuration in it's client.conf file. This file is located in either /etc/pulse/ or ~/.pulse/. Only one of the client.conf files is parsed. So if the user has their own one, the system one will not be parsed at all (this is a point I tried to make in vein on PulseAudio bug #606 - it took quite a while for this to sink in as you can see!).

So we've tried three ways to find a server. If we've still not found one, we just resort to defaults - i.e. connecting to a local, personal daemon and a local system-wide daemon (system-wide use is generally not recommended, but is supported for certainly circumstances - typically embedded systems). If we still cannot connect, the client.conf file can specify whether or not we will try to automatically start a personal daemon. Since PulseAudio 0.9.11, this is the default behaviour and allows console applications to work out of the box without starting a PulseAudio deamon beforehand.

So, in the unlikely event that all that fails, we will ultimately not be able to play sound, but we've done pretty much everything we can to make it work! In order to better visualise this, let's look at a couple of typical scenarios and run through the above process.

Console Application

So, under a default install, we've booted to runlevel 3 and logged into the terminal. We don't set any special variables and start an application that plays sound via ALSA. Here is what happens.

1. App opens default device
2. ALSA PulseAudio plugin (like any PulseAudio client) checks it's config for a server and finds none.
3. It tries to connect to a local server but fail as it is not running.
4. It then starts a PulseAudio server automatically and then connects to it.
5. The application then plays audio via the ALSA API functions and this is ultimately played by the PulseAudio daemon.
6. The client application finishes doing it's thing, and exits.
7. The PulseAudio daemon stays around for a while just incase another app wants to play sound in the near future.
8. After a while, the PulseAudio daemon will go in the huff because no one loves it and kill itself :p

So that's it. It's quite simple. Let's have another example.

X11 Application

Under X11 things are a little bit different, but the same basic principles are followed.

1. During X11 initialisation, modern desktops that support XDG Autostart ultimately run the script start-pulseaudio-x11. This script ensures the PulseAudio daemon is started and some extra X11 related modules loaded into it. These modules ensure that, unlike a console application, the X11 PulseAudio daemon will not exit after an idle timeout - it will instead stick around for as long as the X11 session exists. It als ensures that the X11 Properties mentioned earlier are set - the reasons for will will become apparent in the next example.
2. When any PulseAudio client (be it an ALSA app via the ALSA PulseAudio plugin, or a native PulseAudio) is started it goes through it's "find a server routine". It will now stop this process when it reaches the X11 properties and use the info therein and connect to the server.
3. The client application then plays sound as before and ultimately finishes and extis.
4. The PulseAudio daemon doen't exit/kill itself as the X11 session is still going.

So again, things are actually quite simple.

Remote X11 Application

One of the handiest things with X11 is the ability to connect to another machine on your network and run GUI applications and have them display on your local display. With PulseAudio, the sound is also heard on the local machine. Out of the box (for security reasons), remote connections are not enabled. To enable them, run paprefs and enable the option Enable network access to local sound devices. This is the only option needed for this example. It loads an additional module into the server that listens on TCP port 4713 for incoming connections. Obviously, it goes without saying that any firewall on the machine must allow connections to this port!

1. User starts a normal X11 session and the start-pulseaudio-x11 script ensures the X11 properties are set as in the previous example.
2. User then connects to another machine on his network via SSH and starts an audio player (e.g. RhythmBox, Amarok, etc.)
3. Even tho' the app is running remotely the visual display will be local.
4. When the app starts playing audio, the PulseAudio client portion will find the X11 properties that have been forwarded through the SSH connection.
5. The PulseAudio client will then connect over TCP to the PulseAudio server running on the user's local machine.
6. The User revels in the local display and audio the application provides.

So as you can see, the use of the X11 properties has allowed us to piggy back on top of the X11 forwarding. It's not a totally clean connection as under SSH the X11 data will actually be tunnelled over a secure link handled by SSH itself, whereas all we are doing is telling the PulseAudio client where to connect directly, outside of any SSH tunnels. This means that while the display can work over a NATed system, the sound will not. This is fairly easily addressed, but we'd have to teach SSH about PulseAudio for this to work. The reason it works for X11 is because SSH is aware of, and has specific support for, X11. We're just piggy backing on this. That said, the current arrangement is "good enough" for most use cases.

So I hope this article has demystified how the PulseAudio client and server interact and the various configuration files/variables that come into play. If you have any questions, please ask in the comments and I'll endeavour to update the article.

First of all we should probably explain a little bit about how this works. ALSA is the Advanced Linux Sound Architecture. It is a replacement for OSS (Open Sound System) that had several problem on Liunx and which has ultimately been supplanted by ALSA as the only sound system in the Kernel. Despite a relaxation of license terms and further development on OSSv4, OSS is unlikely to replace ALSA in the mainline kernel.

ALSA also has a userspace component, libasound, that acts as a primary interface to the driver layer. Most complaints about the complexity of the ALSA API actually relate to this userspace component, not the kernel layer which, as you'd expect, is much more rigorously controlled. It does not suffer from the same need to remain backwards compatible with various userspace applications (the ALSA kernel drivers only need to work with libasound which can obviously be developed in parallel) thus leading to a cleaner design than the userspace layer itself which does have to remain backwards compatible.

In addition to interfacing with the kernel layer and interacting with sound hardware physically installed, ALSA also has a plugin architecture. This plugin system allows for devices to be faked/emulated, in various interesting ways. It allows, for example to create a null device that sends all audio to /dev/null, it allows for bluetooth headsets to be used (note this is considered a legacy way these days), and it allows all audio to be routed through PulseAudio which I'll discuss further in a subsequent article.

So, let's talk about ALSA configuration files. Now most of the ALSA config files live in:

/usr/share/alsa/

Arguably these are not really "config" files in the classic sense, i.e. you are not meant to change them as a user according to your own preferences and whims - they are really more like source files and define the structure of various ALSA plugins and multichannel configurations. Unless you are developing/hacking on ALSA, you probably shouldn't tweak the vast majority of the files in this folder.

The main file

/usr/share/alsa/alsa.conf

defines a list of additional files to parse and the order in which to parse them. In order to incorporate PulseAudio in an elegant and configurable way, we make a couple changes to the list of additional files:

--- alsa-lib-1.0.15rc3.lennart/src/conf/alsa.conf	2007-10-17 18:28:03.000000000 -0400
+++ alsa-lib-1.0.15rc3/src/conf/alsa.conf	2007-10-17 18:33:10.000000000 -0400
@@ -8,6 +8,8 @@
 	{
 		func load
 		files [
+			"/usr/share/alsa/pcm/pulseaudio.conf"
+			"/etc/alsa/pulse-default.conf"
 			"/etc/asound.conf"
 			"~/.asoundrc"
 		]

The first file allows us to define a named "device" for ALSA called "pulse". This is always present even if the user ultimately decides not to use PulseAudio by default on their machine. This would allow them to e.g. define a remote PulseAudio server (via Environment variables or client.conf setup - see the next article in this series, linked below) and tell ALSA apps to use this "device" specifically. Arguably this is a corner case, but there is no reason not to support this all the same

The second file allows us to turn on PulseAudio by default. This is a pretty important as offering users a simple way to enable/disable PulseAudio is hightly desirable. PulseAudio roll out is not been completely free from problems and giving users the ability to quickly and easily disable it is essential. I firmly believe that everyone will ultimately use PulseAudio, but it'll take time for every app to fully support it (by removing non-"safe" ALSA API usage) and for driver issues to be worked out properly.

In this second file, we either comment out the file completely to disable PulseAudio by default, or leave it uncommented to enable PulseAudio. This is handled by draksound so the users just see a simple GUI which is a simple but effective solution. That said, I'll probably change this for Mandriva 2010.0, switching to an "Alternatives" driven system although this doesn't really matter in the overall scheme of things!

So when an ALSA application startups up, it parses all these files and ultimately works out how to route your audio. 99% of the time, the "default" device is used (and I use "device" in the loosest possible sense). For a standard Mandriva install, the default device is actually PulseAudio (via the PulseAudio plugin for ALSA).

So what happens next? In the next article, I'll go on to talk about how an ALSA app (or any PulseAudio client) works when connecting to PulseAudio.