PulseAudio

PulseAudio or PA for short is a sound server, a program that fixes a shortcoming of ALSA (also present in the obsolete OSSv3) where each physical device can be controlled by only one program at a time. Of course most people don't experience this shortcoming beause by default systems with ALSA will provide a software mixer known as dmix that allows for multiple programs to share a device. Unfortunately dmix has its share of problems and overall there`s more to be desired from ALSA like
 * networking support
 * per-application volume controls
 * configuration being more user friendly, for sake of argument the current state of ALSA
 * asound.conf uses Lisp
 * alsamixer has a history of misleading control lables
 * better cross-platform support
 * less/no interrupts generated together with large audio buffer, improving battery life

PulseAudio can be thought as higher quality replacement for dmix although it tries to mend the other mentioned shortcomings as well.

PA USE flags
Currently PulseAudio has quite a few USE flags but some of them are more important than others hence only portion of the available USE flags are being explained here.

Recommended

 * alsa
 * PA is the top part of an audio stack hence PA itself needs support for some form of audio output, ALSA being the most common for non-professional systems


 * udev
 * provides hardware detection, helps greatly if ALSA applications are being routed via PA by default (see the plugin for alsa-lib)


 * realtime
 * enables PA to have real-time capabilities with the help of RealtimeKit


 * caps
 * allows PA to drop unneeded capabilities, increasing security


 * orc
 * improves performance of re-sampling (available only starting with PA 1.0)


 * X
 * X11 publish module, may help with setting up sound for networked X11 (also see the official USE flag explanation)

NOT recommended

 * libsamplerate
 * provides exceptionally CPU intensive resamplers that are generally regarded as not worth it


 * system-wide
 * obsolete configuration where PA daemon is run system-wide (be sure to disable the X USE flag if you decide to go with this!)

Relevant USE flags for other ebuilds

 * alsa
 * may be disabled for programms that have some other audio output enabled but leaving it enabled won't hurt


 * pulseaudio
 * please enable this if you want to use PA on your system

PA installation
The recommened way is to set pulseaudio USE flag for desired ebuilds and then run emerge -avuNDt world but if need be PA can be manually installed with emerge pulseaudio.

Making ALSA-only applications use PA
For applications with PA support, no additional setup is required but for ALSA-only applications to be able to benefit from PA, it's highly recommended that media-plugins/alsa-plugins ebuild is installed with pulseaudio USE flag (should be the case but it doesn't hurt to check) and /etc/asound.conf is edited to route them back to PA so that ALSA-only applications too can have improved mixing quality and per-application sound controls among other benefits. If you do this, it's important that udev is being used for hardware detection, else PA itself will be unable to access sound devices without custom configuration.

pcm.!default { type pulse } ctl.!default { type pulse }

Usage
A handy cross-desktop graphical tool is available for setting various aspects of PA. Install it with emerge media-sound/pavucontrol. KDE users can to some extent use Phonon configuration but it's not a full replacement for pavucontrol.

Configuring other applications
Usually PA is used by default if it`s available but some programs require to be explicitly told to use PA. If you know such program and it's not mentioned here, please add it!

MPlayer/MPlayer2
Edit ~/.mplayer/config to something similar to

ao=pulse to make it use PA audio output driver for the current user.

No guarantees on actual latencies
Currently PA provides whatever latency at that moment is possible be it some milliseconds or 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 /etc/pulse/daemon.conf and consider changing resample-method to something less CPU intensive, default-sample-format and default-sample-rate can also affect CPU utilization with floating point, higher bit-depth and larger difference in sample-rate generally needing more resources (e.g. re-sampling 44 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.

Using a version of PA with orc support can noticeably decrease CPU usage, too.

When using fast user switching only first user has sound
For fast user switching to work with PA, it`s important that kernel is compiled with CONFIG_TMPFS_XATTR=y and ConsoleKit is in use. It's also extremely important that no one is in the audio group (not even pulse itself), in fact, regular users don't have to be part of any specific group to have sound access.