PulseAudio

PulseAudio (or PA for short) is Article description::a sound server that provides a number of features on top of the low-level audio interface [[ALSA on Linux]], such as:


 * Networking support (P2P and server mode);
 * Per-application volume controls;
 * Better cross-platform support;
 * Dynamic latency adjustment, which can be used to save power

Prerequisites
PulseAudio uses:


 * sys-fs/udev and sys-auth/consolekit or
 * sys-apps/systemd

Kernel
For motherboards containing Intel HDA sound cards, use the following kernel option for improved power-saving:

Software
Portage knows the  as a global USE flag for enabling support for PulseAudio in other packages. Enabling this USE flag will pull in automatically:

Emerge
After setting USE flags be sure to update the system so the changes take effect:

Additional software

 * - Pulseaudio Volume Control, a GTK+ based mixer for PulseAudio.
 * - PulseAudio Preferences, a configuration dialogue for PulseAudio.
 * KDE's Phonon integrated PulseAudio configuration and mixing, but it is not as powerful as pavucontrol or paprefs.

Permissions
PulseAudio uses udev and ConsoleKit to dynamically give access to the soundcards to the currently "active" nr. When running Systemd this will be handled without needing ConsoleKit.

To make this possible, ACLs (Access Control Lists) are required:

If a desktop profile is not being used, check that or  are installed with the   USE flag enabled, and (if using OpenRC) that  is installed with the   USE flag enabled. ConsoleKit should be running on systems using OpenRC as the init system:

If not, enable it at boot time:

When finished, verify the permissions are working correctly:

Confusing defaults
flat-volumes in scales the device-volume with the volume of the "loudest" application. For example, raising the VoIP call volume will raise the hardware volume and adjust the music-player volume so it stays where it was, without having to lower the volume of the music-player manually. Defaults to yes upstream.

Configuring other applications
Some applications need to be configured to output to PulseAudio by default. A detailed list of these can be found on the PulseAudio wiki's PerfectSetup page.


 * ALSA

The must be installed with the   USE flag enabled:

You need to enable the following module in :
 * OSS

Several GConf keys must be set:
 * GStreamer


 * Manual with :

Enable the following module in :
 * ESD

Also the PulseAudio implementation:

Set the following in :
 * libao

Set the following in :
 * OpenAL

Set the following in :
 * MPlayer

Without udev/systemd
If you are using ALSA as a PulseAudio sink (output) and routing ALSA apps to PA but not using udev, you must set a specific device to be used. Otherwise, PulseAudio will use the ALSA device "default" as the sink, which may be routed back to PulseAudio, forming a loop. To avoid this, add the parameter device=hw:0,0 (you can find the correct IDs by running aplay -l). In the following example, we use two soundcards, of which card 0, device 0 is used as a sink (audio output, e.g. speakers) and card 1, device 0 as a source (audio input, e.g. microphone). PulseAudio will still be able to access other cards than these but it needs these settings to avoid looping the default device in this setup.

Headless server
These instructions are for setting up a headless pulse audio server. Meaning a server which has no display on it but does have speakers. This provides the ability to use the remote server's speakers for audio output.

You will get warned in a dozen places for doing this, but it is the proper method.

Server
First configure USE flags and emerge the package. The system-wide USE flag is masked, so we have to unmask it.

Add the following two lines somewhere in the system.pa file:

Replace 1.2.3.0/24 with the network mask that you want to be able to access the server.

Tell the init script that we really do want to do this, and then start it up:

Client
For a more permanent solution you can add the following to your default.pa file

Now in the pulse audio volume control you should see the remote server listed under Output Devices. Under playback you should have a button next to the Mute audio button that when clicked will let you switch that audio stream to whichever output you want.

Equalizer
Make sure you installed pulseaudio with the  USE flag enabled.

Enabling the required modules
Add the following two lines somewhere in the default.pa file :

Restart the pulseaudio instance. This should be as easy as:

Choosing the equalizer sink
The command should list the index and name of the equalizer sink:

Use or a similar program to select the equalizer sink for sound output. It may be listed as a device starting with FFT based equalizer.

Control the equalizer levels
The equalizer levels can now be controlled with the Qt GUI called.

Known issues

 * Short sound events (e.g. the terminal bell) distort ongoing sound streams (e.g. music)

No sound after installation
If you have no sound while using ALSA, consider unmuting the sound card. Launch and make sure each column has a green   under it (use the  key to toggle mute/unmute). Install and check if there is any output on the pavucontrol panel when playing an audio.

Enable debug mode
To get more informations you need to set the following in :

Afterward restart the daemon:

Audio/Video out of sync
When using PulseAudio over your local network, you can experience out-of-sync problems. Solve this by adding tsched=0:

This disables time scheduling. Afterwards restart the daemon:

Dummy output
If the only playback device is the Dummy Output, PulseAudio cannot access your sound devices. Either the user has no permissions (see section Permissions or another program blocks the access. Try:

It shows the relevant program. Close the program and reconfigure it to use PulseAudio.

No guarantees on actual latencies
Currently PA provides whatever latency at that moment is possible be it some milliseconds to hundreds of milliseconds without regard to what applications ask for.

In case of buffer under-run latencies are never decreased
Currently, if a buffer under-run occurs, PA buffers for longer increasing latency, but it then never tries to buffer for less until restart.

Re-sampling using up a lot of CPU time
Re-sampling can require quite a lot of computational power, PA defaults are rather conservative but in certain cases can still take a significant toll, in such cases edit and consider changing resample-method to something less CPU intensive, default-sample-format and default-sample-rate can also affect CPU utilization with higher bit-depth and larger difference in sample-rate generally needing more resources (e.g. re-sampling 44.1 kHz to 48 kHz is faster than re-sampling either to 192 kHz). Since re-sampling is done per each channel per input, channel configuration and number of applications can affect performance as well.

Starting with version 7.0 there is also soxr resamplers made available by enabling the sox USE flag. In particular resample-method = soxr-mq should provide acceptable quality while even the higher quality and hence slower soxr-hq is still cheaper than the default speex-float-1. But be warned that the soxr resamplers have roughly 5-20 times higher latency than speex-float, in terms of time the worst case for soxr-mq/hq can be as high as 20 ms while soxr-vhq latency can in few specific setups reach over 27 ms. In terms of feeling 20 ms can range from unnoticeable to irritating depending on person and use case (the usual PA latency's lower bound is around 20-25 ms and more commonly often around 70-90 ms, for comparison).

grsec and PulseAudio
Make sure CONFIG_GRKERNSEC_SYSFS_RESTRICT is not enabled if you are using a grsecurity kernel. PulseAudio’s module-udev-detect needs to access to discover what cards are available on the system, and that kernel option disallows this for anyone but root.

FAQ
See PulseAudio's Frequently Asked Questions.

External resources

 * PulseAudio: The Perfect Setup
 * Why you should care about PulseAudio (and how to start doing it)
 * More general troubleshooting tips