PulseAudio is a Linux sound server that, through abstraction layers, promises a myriad of flexible audio features: combining multiple sound cards into a single, multi-channel device, changing output devices on the fly for running applications, even redirecting input and output between machines over the network. Sadly, though, it is usually used just as a bare-bones drop-in replacement for older, buggier sound servers like ESD — because that is the most common use case, and because the PulseAudio documentation and tools aren’t caught up to the same level as the underlying library. Full PulseAudio nirvana entails digging into the project in depth, but you can at least get your feet wet over the weekend, directing and even multicasting audio between Linux machines on your local network.
Initial Setup
PulseAudio is the default sound server for most GNOME-based desktop Linux distributions, so after installation, the GNOME desktop’s PulseAudio configuration should work with most general-purpose applications that produce audio output. Unfortunately there are always exceptions, most often among dedicated multimedia apps that prefer to behave according to their own configuration rules rather than broader standards. The list can include video players like MythTV or MPlayer, or audio conferencing tools like Skype. You should go ahead and install all of the PulseAudio packages provided by your distribution — particularly paprefs, pavucontrol, and pulseaudio-utils.
If you experience trouble with a particular app, start by consulting the PulseAudio wiki’s Perfect Setup page, which documents how to configure the behavior of a variety of specific applications. If you still can’t sort out the application in question, it is best to visit the discussion forum for your Linux distribution — all to often, small differences in configuration details like autospawning daemons and buried preferences are the culprits.
KDE-based distributions normally use the Phonon audio layer. Luckily, all Linux audio layers provide so much abstraction that it is almost always possible to map any pair of them to each other, and using Phonon on top of PulseAudio is no exception. Start by installing all of the available PulseAudio packages as described above. You will then need to open System Settings / Sound and choose GStreamer as the default backend. Then, go to Settings / Multimedia System Selector / Audio, and select PulseAudio.
Whichever desktop you use, open the PulseAudio Volume Control application: from a command line, run pavucontrol &. What you’ll see is an app with five-tabs: Playback, Recording, Output Devices, Input Devices, and Configuration. Playback and Recording show only activity from running applications, so they are not much use when you first get started. Have a look at Output Devices and Input Devices, though — both of these tabs list all of the available audio routing options that PulseAudio currently knows about.
At the bottom you’ll find a selection box that lets you display only physical devices (i.e., actual sound cards) or other subsets of the total. The key to sharing audio is setting up virtual devices in addition to the physical. First we’ll set up a virtual device for remote access to a particular machine. Once we get that working, we’ll set up a virtual device that multicasts audio to every machine that wants to hear it.
Share and Enjoy
Launch the PulseAudio Volume Control app (if it is not already running) on all of the machines you intend to route audio between, and launch the PulseAudio Preferences app with paprefs & as well. This Preferences window is far more than a simple customization utility; it activates and deactivates several high-end features if you know where to look. There are four tabs: Network Access, Network Server, Multicast/RTP, and Simultaneous Output.
For routing audio from one machine to another, we’ll use just the first two tabs. On each machine that you wish to use as a sound source, you must enable the “Make discoverable PulseAudio network sound devices available locally” option in Network Access. Conversely, on each machine on which you wish to receive and play back sound, you must enable the Network Server tab options — primarily “Enable network access to local sounds devices,” though you should probably check both options beneath it to permit auto-discovery and not require authentication. If you are not sure what your usage pattern will be, it is safe to enable all of the options on all of the machines.
On a corporate network, the discovery and authentication options may be a security risk (consider eavesdropping), but for testing and home use it sidesteps a lot of troubleshooting. If the client/server distinction of these options seems intuitively backwards, it’s not your imagination. Just remember that it models the same distinct definition of client and server that X Windows popularized; it will eventually make more sense.
With both options enabled on the test machines, switch back to the Volume Control window and look at the Output Devices and Input Devices tabs. You should see new entries in each, representing sound cards discovered by PulseAudio on the other machines. Each will be labeled with a less-than-user-friendly name composed of the original machine’s hardware device name (such as IDE1712[Envy24] PCI Multi-Channel I/O Controller Digital Surround 4.0 (IEC958) followed by “on someusername@somehostname” where the username is the logged-in user and the hostname is that of the remote machine. Unless you have multiple sound cards of the same type on your computers, the hostnames are probably sufficient to tell you which virtual device is which.
The virtual device setup is now complete, but in order to actually route audio, you must start an audio stream. Launch an audio application (such as Banshee, VLC, or Amarok) on one machine, then switch to the Playback tab on that machine’s Volume Control. The playing app will be at the bottom of the list; to the right of its name you will see a selection control that lists all of the known audio devices — and the local hardware device will be the one selected. Just click on the button and select the sound card on another machine to route the audio there instead.
Apart from having a deeply misconfigured sound server to begin with (such as one that cannot play back audio locally at all), the only significant trouble you might encounter is if PulseAudio does not auto-discover the remote machines that it should. In my tests, when this happens, the quickest fix is to deactivate and then re-activate the Network Access tab option on the sound source machine — this forces a rediscovery. You can also try de- and re-activating the Network Server option on the sound receiving machine, but I have not found it as reliable a fix.
And lest you think that you’ll need to jump through all of these hoops every time, try quitting the audio playing application. Now restart it and start playing again. You should hear it on the receiving machine automatically — PulseAudio remembers how the audio stream was routed.
This option is a good way to share audio between two machines that are physically separated. For example, you will notice that “System sounds” is a listed application under Playback. You can route system sounds from the far-away machine to your desktop and be sure you’ll hear any sudden warning bells. You can even turn on your desktop’s screen reader for speech output and have it read notifications out loud.
On the other hand, you cannot use this method to share audio between three or more machines, so you cannot start a podcast on one computer and pipe it all over your house and out to the garage. To do that, you could drop to the command line and hand-create a stack of virtual devices the old-fashioned way, but it is much simpler to use multicast.
Multicast
PulseAudio’s multicast capabilities use the Real-time Transport Protocol (RTP) also used for delivering media payloads by SIP and other VoIP protocols. On a local network segment, you should not have any trouble turning it on and receiving the stream, but if you cross a firewall or router, you may need to check that RTP is permit to cross over without filtering.
The Multicast/RTP tab of PulseAudio Preferences holds all of the required options. The main choices are intuitive: “Enable Multicast/RTP receiver” and “Enable Multicast/RTP sender.” Any sound source machine needs to be enabled as a sender, and any receiving machine as a receiver; as before it is safe to enable both on a machine.
What are not quite as clear are the options beneath “Enable Multicast/RTP sender” — you must choose between three seemingly unrelated options: “Send audio from local microphone,” “Send audio from local speakers,” and “Create separate audio device for Multicast/RTP.” Fortunately, for general-purpose usage, you can just choose the latter option and forget about it. The first two are useful for setting up an always-on broadcast stream that is probably not what you are interested in. Last but not least is the “Loop back audio to local speakers” check box; check this to keep any audio to choose to multicast playing on the originating computer as well.
With these options enabled, you can go to the PulseAudio Volume Control application and set the Playback for any audio application to “RTP Multicast.” All audio produced by the app will immediately begin playing on the receiving machines.
In practice, the quality of audio using RTP can be a source of frustration. It consumes bandwidth, even when multicasting silence, and if you have network congestion you may receive choppy audio because of dropped packets. That is less likely to happen with a direct PulseAudio route as in the previous section, because RTP uses UDP and is designed to drop packets if they arrive “too late.” On top of that, you will need more CPU power to simultaneously multicast an RTP stream and loop the audio to the local speakers. On the other hand, this solution certainly uses less bandwidth than running multiple distinct audio routes, so it is the best option for widely distributing sound.
If you made it this far, you may be wondering about the “Simultaneous Output” tab in PulseAudio Preferences. This feature, when activated, creates a virtual device that represents all of the hardware devices on the local machine. In other words, if you have just a single sound card, it adds no additional features and further lengthens the list of Output Devices. But you can use it to send sound such as system alerts to multiple sound cards — very helpful if you use one card for speakers and another for a VoIP headset, for example.
Further Work: Doing It All the Hard Way
The Volume Control and Preferences tools require you to march through quite a series of steps to simply move a single audio stream, but the good news is that they work. The previous generation of PulseAudio GUI tools didn’t even do that (PulseAudio Device Manager and company). But the reason that the GUI tools work and continue to work on multiple application settings is that PulseAudio secretly notes the configuration changes you make and reloads them. Take a look at the .pulse directory in your home folder and the “system / pulseaudio” section of GConf if you use GNOME.
If you just found the GUI interface too user-friendly, consider digging in to the PulseAudio documentation and figuring out how to replicate the same behavior in the standard text configuration files. The cowboy way is to edit the /etc/pulse/system.pa file on each machine, and restart PulseAudio from /etc/init.d.
But don’t do it just for the bragging rights. Do it because you can also build more complex virtual devices once you understand the syntax, such as a device that provides “simultaneous output” to both a physical sound card and an RTP multicast stream. Doesn’t that … sound interesting?
