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

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

The Test button now selects the right device. The way of achieving this is a little convoluted, but it seems to work well. We now generate a UUID for every phonon stream and push this into the PulseAudio stream proplist via an environment variable. We then look for all the streams in pulse and match up our UUID such that we can match up the pulse stream index to our phonon stream. We can then use this to move the stream to the appropriate device. Due to the async nature of PulseAudio, phonon sometimes requests the move before the stream is actually setup, so we have to queue up the move requests and process them when a stream appears. This approach also has the effect of causing the specific sink to be saved in module-stream-restore database, but this shouldn't matter in practice as phonon will always move it, so if the priority list changes, then we will always set the right device one way or the other even if the whole rigmarole could be avoided. But like I say, the practical outcome is fine, so let's just leave that for now.

The category is also passed through to PulseAudio now, so the the only thing that is not handled is when PulseAudio disconnects/restarts. Thankfully this is now getting less and less often as stability improves

For several releases we (Mandriva) have been patching KDE's phonon support to hide all the real devices if PulseAudio is used because the GUI really makes no sense (PulseAudio handles all the routing for us). This is an acceptable solution but it's far from ideal.

So with the latest set of three patches (one for pulseaudio, one for phonon and the final one for kdebase4-runtime) I now have a fully working system (albeit with some caveats!).

So how does it all work? Well The first step is module-device-manager. This is a pulseaudio module that does the following:

• Store all devices we've ever seen and keep track of their description and their icon.
• Provide a protocol extension to allow clients to query this database.
• Implement a per-role priority list for devices (again exposing it via the protocol)
• Implement a routing policy that will always uses the highest available device for streams with the relevant role.

With that in mind, I then patched Phonon to support querying this database and editing the priority list. Normally (e.g. when pulse is not in use) phonon will keep all it's configuration in a simple config file, so I've overridden this when pulse is detected (which now happens via trying to connect to the server, rather than relying on Mandriva specific configs) to instead use our little database.

The final step is a patch to kdebase4-runtime. There was some copied code kicking around which caused a lot of issues with this patch. In the end I had to export a new config class from phonon in order to make this all work (I don't want the KCM tweaking the config file as it will not be used if pulseaudio is in use... so by exporting the config class everying is kept abstracted).

All in all, this means that:

• All the sinks/sources from PulseAudio are shown in the System Settings -> Multimedia dialog
• You can order the devices and this will be honoured and saved to pulseaudio. Audio will be routed according to this preference.
• Devices that are unavailable will be shown greyed out.
• When devices appear/disappear, they will be automatically used if they are higher up the priority list than what's currently being used.

But with all good news there is some bad news! So what's not working?

• Categories are not currently mapped to roles, so the only category list that works is the "default" one (although some applications may have their role guessed by PulseAudio because it parses the data in an applications .desktop file.
• Testing a device will not test the specific device you've selected. PulseAudio handles all the routing, so there is no way to force a given device to be used. I'm not sure how to handle this ultimately.
• Doesn't handle a PulseAudio restart (aka a crash and respawn!)

The phonon patch is being reviewed for upstream inclusion but the API exposed is liable to change, so these patches are not final. Likewise module-device-manager is not yet final and may yet undergo some API changes. But that aside, this is IMO great progress even if I do say so myself!

And what is a blog post without a screenshot eh? OK here you go:

All my git repositories can be found here.

I only saw one 64 bit package so I figured I'd convert it. It's for Ubuntu, but alien -r skype.deb soon converts that to an RPM. Sadly it turns out that this is not a 64 bit app at all, it's just 32 bit but presumably it's got the necessary dependancies cooked into the package. So overall, the Fedora package will probably run fine on Mandriva.

Once it was installed I fired it up and under sound preferences it just says "PulseAudio" all the way Happy Days.

I found that Skype seemed to try and change volumes a bit and that seemed to trigger an assert in pulse so I disabled the relevant setting in Skype for now and things seem a bit more stable since then.

Now, PulseAudio has some nice features, like corking (pausing if the app supports it) music playback when a call comes in. In order to do this, PulseAudio has to know that Skype is a telephony application. In theory this is just a matter of adding "Telephony" to the Categories in the skype.desktop file. Sadly this didn't seem to work for me... not sure why, but I didn't debug for too long. Instead I added a

X-PulseAudio-Properties=media.role=phone

That did the trick. Pulse now knows that Skype is a VoIP app

One other neat feature (in addition to the music pausing) is that when I connected my Bluetooth headset half way through a call, PulseAudio moved my call across to the headset automatically! Nice.

So the conclusion? Well, there does still seem to be a few issues with the volume setting but overall, this is a great step forward!

So what next? Well work out why the asserts happen on volume changes and then work out why the Telephony category is not parsed from skype.desktop.

ALSA vs OSS

A lot of the comments of late have been discussing things such as how amazingly brilliant OSS is. Personally I don't buy it. I've never really played overly much with OSS and as such this is probably a slightly ill-informed view - although that's not to say it's not accurate of course . Most of these kind of comments are made by people who don't really understand ALSA and are bought over by the "ALSA API is overly complex" type comments. Yes, the ALSA client library is rather complex and has numerous pitfalls - so much so that there exists now an unofficial "safe" ALSA Subset API. But what people invariably fail to comment on (and thus fully understand) is that ALSA comes in two parts: the kernel driver and the userspace library. ALSA differs from OSS in that all access to the kernel layer is performed via a userspace library. I don't know of any ALSA clients that communicate directly with the kernel layer without going through libasound. What this means is that the kernel interface has the freedom to be re-factored and improved at any time, provided the userspace library is developed in parallel. For this reason, the kernel layer is actually quite clean and well defined. The rather rigorous quality control that goes on in the kernel is testament to the fact that on the kernel side of things, ALSA is doing pretty well. Of course there can (and will be) improvements in this area in the future, but this side of things is certainly not in a poor state as people seem to assume.

The "too complex" argument relates to the ALSA userspace API. In order to remain backwards compatible, the userspace API has undergone several refinements. As will anything not designed from the top down, some parts of it are rather confusing and have sometimes been misinterpreted (the classic example here being the confusion over snd_pcm_delay() - it's documentation hinting at a hardware based implementation that subsequently lead to some project (i.e. WINE) assuming that this function will eventually return 0 which is not true; fortunately this problem is behind us now, but with a new API call added that does return the info the WINE guys (and others) needed).

So yes, the ALSA userspace API could use a complete top-down redesign, but in order to do that, we would immediately break compatibility with 90% of the apps out there: Not a great idea all in all. Retaining backwards compatibility is a pain, but it's also quite important!

But Sound Servers Suck!

What is in a name? That which we call a rose by any other name would smell as sweet. Some people seem to have some sort of built in hatred of "sound servers" as a concept without really thinking through what this means. Yes, there have been some pretty awful experiences with some sound servers in the past (EsounD and aRTs being the immediate examples that spring to mind), but that doesn't mean the concept itself is flawed. You may drive a couple of shit cars but doesn't mean we should all abandon the roads. In addition, the sound servers of old were really just mixers. In the old days most hardware was not capable of doing hardware mixing and thus couldn't produce sound from multiple apps at the same time, so a mixer was an essential component. Nowadays, software mixing is the norm rather than the exception, even on high end hardware, and ALSA itself has a pretty solid sofware mixing in the form of DMIX, thus obsoleting large parts of the previous sound server functionality - certainly making the additional features they did offer seem disproportionate to the hassle they introduced. In the early days DMIX was just another sound server. Apparently this has changed these days, no longer needing an additional process. While it achieves the job of software mixing very well, it's not as fast or as flexible as other solutions can offer.

Modern Multi-user Desktop

So, these days a modern, multi-user desktop is quite a different beast to what it once was. Components such as Console Kit track which users are currently active (e.g. when more than one user is logged in simultaneously) and tells udev to write appropriate ACLs to enforce this policy. Users also want to use network attached sound systems, such as Apple Airtunes (RAOP) devices and UPnP media renderers etc. not to mention Bluetooth devices. All of this is much further up the sound stack than the low level driver level and has to deal with various permission and authentication schemes. This obviously needs a userspace component to govern this interaction. Something has to be responsible for this and a "sound server" of some sort obviously fits the bill perfectly.

PulseAudio

So enter PulseAudio. It's had it's fair share of bad publicity, but ultimately this important part of the Linux sound stack is taking on several roles that are important in a modern desktop. It's dealing with several different things:

• Software mixing
• Independent (per-application) volume control
• Dealing with permissions (is the user allowed to access the sound device?)
• Dealing with Bluetooth devices
• Dealing with Network based devices (UPnP, Apple Airtunes, Native PulseAudio etc).
• Handling the moving of streams between outputs.
• Handling sound from remote applications run via X11 over a network.
• Dealing with routing policy (Music goes to USB speakers, Desktop sound events to built in speakers, VoIP to Bluetooth headset)
• Effects to promote HCI (e.g. positional event sounds  - button clicks etc, coming out louder on the left hand speaker when triggered from the left hand side of the desktop)
• Power Consumption and Efficient savings.
• Reduces risk of buffer under-runs.

So the people who talk about OSSv4 and how it can do mixing and per-app volume control and how this means that ALSA and PulseAudio are not needed are totally underestimating what's needed in a modern audio stack. There still needs to be some kind of userspace daemon to govern these other sound systems and deal with multiple users. This is a non-trivial job and no other system out there is currently aiming to implement these capabilities.

One of the often overlooked advantages of PulseAudio is the "glitch free" system. This is an approach that ultimately disabled interrupt driven audio and instead relies on system timers. Modern kernels can provide these timers easily and reducing the number of interrupts and using larger buffers allows you to greatly reduce the number of CPU wake-ups thus saving power. This is actually a very important technique to implement when dealing with modern mobile platforms.

Reuse

It's obviously important to ensure efficient code reuse. It doesn't make sense for all sound producing applications to implement direct support for "exotic" sound systems such as Bluetooth, UPnP and Apple Airtunes etc. To do so is very inefficient (there are some exceptions to this - e.g. a media player that targets Win/Lin/Mac will maybe need to implement direct support if it is to be available across the board). Keeping the implementation centralised and having a single app->sound system API is essential here.

Consistency of UI

One of my big problems with many applications is inconsistent UI. This is a problem on Windows as much as on Linux, but it's something OSX has done mostly right. Users got to a central GUI to configure their sound and which device is currently active/in use. In Linux land all sound producing apps have their own config GUI for selecting sound devices. This is insane. Non-technical users don't know that you have to go to Tool->Preferences->Advanced->Sound in App A and Edit->Settings->Audio in App B. Sure, those of us who are reasonably technical will generally find the options (that's how we use applications - we click and look at all the settings pretty early on!), it's going to be less than obvious for a massive number of users. Keeping the preferences centralised so the user always know where to look is important and for a general purpose application that outputs sound, there should be no reason to provide any config option relating to this to the user - it should "just work"(tm).

Incompatibility

Some users have complained that some proprietary applications have stopped working with PulseAudio, Skype being an oft mentioned example. Well, I'm sorry but that's just tough. If a closed source application does not implement an API cleanly and does bizarre things, there is nothing we can do to fix it. The problems Skype has experienced with PulseAudio would also be experienced by any other plugin to ALSA. I'm sorry to say it, but in order to move forward, some applications have to suffer and/or be forced into action. By not allowing the people who care about this stuff the right to improve things themselves you're taking on the responsibility to do this yourself and you need to live up to your responsibilities. Considering the last version of Skype for Linux was released more than one and a half years ago, it's hard to consider it as anything more than abandon-ware at present. Will there be more pain like this? Yes, probably but that's just way things are - Free Software only truly works if the whole bundle is Free, if you mix and match you, as a user, have to accept this state of affairs. I do.

Desktop environments need to ensure they integrate nicely with PulseAudio. GNOME is obviously doing this, but KDE is lagging behind. I do hope to rectify the latter situation personally, and have a pretty clear roadmap to making this happen - it's just a matter of finding the time to do it!

Conclusion

So, with all this in mind, the sound stack has to be more than just a driver layer. It needs a persistent userspace layer that can run and keep track of various permission problems, deal with network connections and generally govern things. At present PulseAudio is fitting the bill pretty nicely and is continuing to add support for additional constructs in the Linux stack. As things stand all the major Linux distributions are now using PulseAudio with commercial interest from Nokia, Intel and Palm among others.

Future

So the future? Well, the drivers in ALSA need to be further debugged and developed to ensure the accuracy of the timing information that has so far plagued the "glitch free" system in PulseAudio. Nothing has pushed the ALSA drivers to such limits before, but the benefits of the glitch free mode are clearly worth the pain. Applications using the ALSA API need to ensure that they are using it correctly and sticking to the safe subset whenever possible (thus ensuring compatibility with PulseAudio's ALSA plugin). In addition, applications such as media players need to deal properly with latencies. It's a bit of a myth that low latencies are needed by such applications - higher latencies will ensure better battery life on mobile players and depending how the user wants to route their sound (e.g. to the Bluetooth enabled hi-fi system) latencies will be something beyond the control of the application in any event. It's therefore important to deal with this correctly and appropriately to ensure A/V sync. It's only been about half a year that the ALSA level limitations on buffer sizes were lifted after lobbying from the PulseAudio maintainer. Intel are even experimenting with 10 second buffers (that's not the same as latency!) in order to save power!

Every day more and more applications are tightening up their ALSA implementations. Every day the constructs of the Linux desktop are becoming more stable and solidified, offering a truly joined up multi-user and network aware experience. I think this is particularly impressive considering the fact that (as far as I know) only three people are employed to look after the Linux sound stack: Takashi Iwai andJaroslav Kysela on the ALSA side and Lennart Poettering on the PulseAudio side. While there are numerous other contributors, this is still pretty impressive progress with the resources at hand. It's also worth noting that two of the three are employed by RedHat, the other by Novell.

While Mandriva will still provide an easy way to disable PulseAudio if you feel it's not right for you (just untick the box - it's not hard!!) or need to use these closed applications such as Skype, I believe that this will not be necessary in the not too distant future.

So where is Sound on Linux? In my opinion it's in a pretty good state - there are still lots of things to do, and that will never change, but there is a firm and solid framework out there now and it's getting better every day.

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.