A few budding developers have asked me recently about this and to make life easy, I decided to write up this guide! There are some gotchas to look out for so please read carefully!

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"

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.

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

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.

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:

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:

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:

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:

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.

Since its initial release, people have had issues with PulseAudio and audio playback. The developers often had said that Distro Suchnsuch weren’t building and incorporating Pulse properly, that the software would work fine if Distro Suchnsuch knew what they were doing.

The pulse debate lives on, and now you’re showing users how to build their own Pulse, when supposedly their distro maintainers cannot get it correct? Or have things finally been resolved in Pulse and I missed it?

Besides I think you totally trivialise the problems down to a simple “compilation” issue. I mean do you really believe that distro X *compiles* PA incorrectly? These are not the issues at play in a properly defined PA deployment. It relates to ALSA configuration, various different backends to audio libraries (i.e. gstreamer, vlc, libao, portaudio, SDL etc.), the support compiled into various system components (i.e. in GNOME, KDE etc.) and the default configuration of many individual applications. It not just a simple matter of compiling one package correctly and everything works fine.

My Advice here is how to run the code from git so you can hack on it. Various issues regarding how the rest of your distro and/or user configuration works with PA are not covered in this article.

Most distros still default to PA and even more KDE focused distros are doing the same now that I’ve written the majority of the integration code.

So please rephrase your question to ask about specific details so I can address them specifically if the above reply doesn’t answer your questions.

Thank you for the response. I am not familiar at all with Pulse and I am not using it, I am just curious if many of the issues had been ironed out or not. If sound integration doesn’t work due to configuration of files, not the compilation of code, then yes that would answer my question.

I don’t have a specific distro to point at, I’ve just read a lot of back-and-forth over the years about Pulse being great and Pulse being broken.

Thanks, this is really useful! Now I’m looking forward to the next guide: “Debugging PulseAudio with gdb” – just adding “gdb –args” in front of the argument won’t work as that will go to the autotools wrapper script, etc…

Yeah I’ll try and sort something out about that. (I’ve not tried but I think there are two options – one is to use the wrapper script once, then call the binary directly after that – the first run will relink via the wrapper script and the second run it should be OK…. the other is to run gdb and attach to the running PA instance: this is how I prefer to do it, but it obviously doesn’t help if PA is crashing on startup!)

Hi, I follow your instruction to download the pulseaudio package but failed to find the “configure” script to configure my source code. I cannot see this file in git tree either. Can you tell me how to fix this? Thanks.

Hello! You missed the “bootstrap” stage, which generates the configure script. Sadly when double checking the article, I realised I’d said to run “./bootstrap -V” but in actual fact you need to run “./bootstrap.sh -V” (I had missed out the .sh extension!) Sorry about that. I’ve fixed it now!

Hmm, not too sure why it would bail out… I guess there is some kind of missing file needed for building there? Perhaps if you try rebuilding your distro’s package for pulseaudio first? It will make it easy to install all the required development libraries and headers needed.

Just as a guess from the 2nd last line, does “which gettextize” actually return a path on your system? I have it in /usr/bin.

I think the main problem is you’re running things as root. You should always just use your normal user account. Check which user is running the current PA process and just stick with using that user and pulseaudio -k should work fine.

I also suspect that the other problems also relate to running the daemon as root.

But at the end you say the process is stuck and runs forever….. well this is what is expected. You can of course put it into the background and use it as a normal install but this guide was written with a debugging and development perspective, so I run it in the foregroud. If you were running it as a background process, it wouldn’t really make sense to pass -vvvv argument which enables the verbose debug output.

Yes if the “Daemon terminated” line is shown, the paplay will certainly generate a “Connection refused” error (as there is no daemon to connect to).

What was the output from the configure stage? It should print a summary of what is and is not going to be compiled. Do you have all the necessary build dependencies to build console kit support?

I grant you that if you do not enable console kit in configure, that the default.pa should work – I’ll add some ifexists around that to protect it from this.

But the fact you are using module-detect makes me thing you do not have udev support compiled in either. As I mentioned in the article, pay particular attention to the summary at the end of the configure stage. Make sure you include all the bits you really want (and you really do want udev and consolekit support!!).

(I should clarify that consolekit is dependant on dbus – so if the line “Enable DBUS: no” appears in your configure output, this is the problem!; ensure that you have udev and dbus support – you really want both!)

OK, I’m not really sure if you’re describing a problem any more. Anyway, the kind of advice is now beyond a blog comments section I think. If you still don’t manage to get things working, then feel free to drop by our IRC channel or post on the mailing list for advice.

Is there a way to use paprefs with this local build of pulseaudio? Even when setting the LD_LIBRARY_PATH correctly and creating the symlinks, paprefs won’t allow me to toy with the network settings (they are greyed out).

Ahh good point. paprefs should do runtime module path detection to allow it to know which ones are installed, but it may not work properly with this approach. One thing you can do is run paprefs with the system version of PA and enable the options you need. paprefs should just be a frontend to gconf so enabling things for the system version should allow it to be enabled for the self compiled version. I’ll try this out later myself to double check, but it should work

Not quite sure why it wouldn’t have worked. Try looking at pacmd list-modules output and making sure that module-gconf is loaded. Perhaps try looking at the debug output to work out whether or not the gconf module is behaving correctly.

Moving on, I went to patch the source and discovered that the patches had already been commited to the source. So I went head and started compiling as detailed in this guide. After a little bit of playing (and having to upgrade ALSA to 1.0.24), I got the dev branch to work.

Sorry for the late reply. I hope you’ve got things working by now? If not just drop by our IRC or mailing list to ask for help and advice. I can’t say from the above quite what’s wrong, but I’m sure we’ll get to the bottom of it

Have a question. After command ../configure –prefix=$(pwd) it shows the error(at the end of output):

checking whether to build static libraries… no
checking ltdl.h usability… no
checking ltdl.h presence… no
checking for ltdl.h… no
configure: error: Unable to find libltdl version 2. Makes sure you have libtool 2.2 or later installed.

That’s the runtime library. You’re likely missing the development package. Easiest option to ensure you have everything installed is to download the fedora SRPM for PA and then try and prepare the (rpmbuild -bp) It will warn you if you do not have any of the “BuildRequires” installed. That way you should be good to build the source outside of the SRPM. HTHs

Your PA configuration is likely not configured to autospawn (or there is some problem with that configuration). If it’s not configured to autospawn, paplay and any other audio client application will not launch the PA daemon and thus you have to start it manually.

Please use AM_GNU_GETTEXT([external]) in order to cause autoconfiguration
to look for an external libintl.

Please create po/Makevars from the template in po/Makevars.template.
You can then remove po/Makevars.template.

Please run ‘aclocal -I m4′ to regenerate the aclocal.m4 file.
You need aclocal from GNU automake 1.8 (or newer) to do this.
Then run ‘autoconf’ to regenerate the configure file.

You will also need config.guess and config.sub, which you can get from the CVS
of the ‘config’ project at http://savannah.gnu.org/. The commands to fetch them
are
$ wget ‘http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/config/config/config.guess’
$ wget ‘http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/config/config/config.sub’

You might also want to copy the convenience header file gettext.h
from the /usr/share/gettext directory into your package.
It is a wrapper around that implements the configure –disable-nls
option.

You simply don’t have the necessary build time dependencies installed. There is a massive clue on the last line of your log: intltoolize: command not found. So you should install whatever package gives you that command on Fedora. You should likely install all the other build time deps mentioned in the fedora packages. e.g http://pkgs.fedoraproject.org/cgit/pulseaudio.git/tree/pulseaudio.spec?h=f17 (although this is for an older version of PA, so the deps from the newer fedora package might be needed too). Ultimately this is not specific to PulseAudio – this is simply standard autotools stuff. You should be able to solve these problems easily enough.

Also, you should not run the command via sudo. There is no need to be root during any point of the build process. Depending on the configure options and the install prefix chosen, you may need to be root for the “make install” stage but that’s it.

If you are not building PA to hack on, I would strongly suggest making an updated package instead. It keeps your system much cleaner that way.

Thanks for reply!
I am trying to compile pulse audio and using it on ‘Tomato Usb by shibby’. I’ ve tried on Mandriva 2011 but i don’t know how to install git repo, so maybe it would be easier on Mandriva getting git instead of installing those packages at Fedora.

Whether it’s Fedora, Mandriva or (my distro of choice) Mageia, the steps are approximately the same. Installing git on Mandriva or Mageia are both simply matters of installing the correct packages (IIRC on Mandriva 2011, it was called git-core or git-scm or something due to it conflicting with an existing project also called “git”). Regardless, you’ll still have to install the required development packages to build PA from git on Mandriva or Mageia in exactly the same was as on Fedora! I think you’ll just have to do a bit more reading on development on linux systems generally to get a feel for how this kind of stuff works overall before jumping into specific cases