PulseAudio
PulseAudio ( formerly called polypaudio, see below) is a network- transparent, platform- independent sound middleware whose API on concepts of them detached Enlightened Sound Daemon ( ESD ) derives.
The client libraries are usable on any network-enabled platform ( for example, embedded or mobile devices), the PulseAudio daemon as a central sound server and hardware interface and the associated utilities are available on all POSIX - compatible systems and Microsoft Windows.
PulseAudio is free software under the terms of the GNU Lesser General Public License.
Operation
PulseAudio is based on two fundamental principles:
- All audio streams are passed through the PulseAudio daemon ( sound server ).
- Only the PulseAudio daemon itself accesses the hardware sound interface to ( software abstraction of the physical sound hardware ) of the system on which it runs.
Few programs can not communicate with PulseAudio:
Most programs can communicate directly with PulseAudio:
PulseAudio is also network-compatible:
Without PulseAudio the program directly with the sound card driver (in this case an ALSA driver) communicate:
Alternative programs should communicate with the ALSA sound server:
This results in both advantages and disadvantages:
Benefits
A central concern of PulseAudio is on the one hand, the applications largely separate from the actual sound hardware ( abstraction ), but on the other hand to give them more influence on the behavior of audio streams, without the complexity of excessively enlarging ( with metadata ).
This is achieved by the above principles, the basis of which all processes are forced to surrender their sound data to PulseAudio. This eliminates the responsibility of the individual programs for the sound data and is in a central location, namely the PulseAudio daemon bundled. Its interface allows to influence the audio data without the individual processes are involved in some form in it.
Disadvantages
First and most obvious consequence is that only programs that use the PulseAudio client libraries are able to use Soundein or output streams. As long as no legacy applications are used, this is not relevant (almost all current audio and media player and most portable audio libraries (such as OpenAL or SDL) support PulseAudio directly ).
Thus PulseAudio though ideally seamlessly even when using older programs into the system, a number of specialized applications have been developed together with the actual sound server. These adapters mentioned programs are on the one hand normal PulseAudio clients, but on the other hand they offer processes also access over others, also usually exclusive, audio interfaces, the data are then processed transparently via PulseAudio without the part of the legacy programs necessary changes are. Due to the variety of these adapters, the original name was polypaudio.
An example is the use of Linux, where as a hardware sound interface normally ALSA is used: While a few Linux drivers for sound cards Mixing in hardware support entirely, and also ALSA also even by default a simple software mixer in the form of dmix plug-ins brings and so theoretically the PulseAudio daemon can be operated in parallel to pure ALSA applications, a different approach is usually trodden: Instead of Dmix plugins ALSA - PulseAudio adapter is loaded, the PulseAudio channels as ALSA sound devices the applications provides. The physical ALSA devices are banned from the PulseAudio daemon in the exclusive access and the Pulse Audio Adapter as the default audio device for ALSA. To use all the programs that use ALSA, PulseAudio automatically. Whether the daemon itself the ALSA hardware uses for sound output or not, does not matter.
Thus it is possible, even on a system that has no physical sound hardware and audio output, for example, done via a connected via Wi-Fi audio amplifier to use normal ALSA software without modification.
There are restrictions when programs specific hardware characteristics or behavior expected by the adapter can not be emulated (eg fixed RAM Locking or a specific device numbering), as well as in mixed 32/64bit systems, if not all libraries in both versions are available.
The interface to the older Open Sound System (OSS ) can be emulated by ALSA ( aoss ), but PulseAudio also provides its own adapter ( padsp ) provides that manages the OSS device files created ( for example, / dev / dsp ) itself and.
Programs that expect instead of PulseAudio still the Enlightened Sound Daemon ( ESD) are directly supported because PulseAudio acts as a complete replacement for ESD and its interfaces has taken over.
Device independence
The individual audio streams are not tied to a specific hardware and can without the associated processes are influenced by it, to be diverted in operation on other devices. This can be done manually using the functionality provided by the PulseAudio utilities graphical interface, as well as automatically. For this is PulseAudio a scriptable interface, which is used for example when connecting or disconnecting a sound device. Through user- defined preferences can be so certain sound hardware ( if available ) can be compared with other preferred.
An example is the use of a notebook, the sound output switches to connect to the docking station automatically by the built-in speakers to the wireless amplifier and the sound input to the fixed microphone, without this resulting in an interruption of the audio streams. When removing from the dock, the reverse effect occurs.
Preferences can be multi-level, for example, a Bluetooth or USB headset again have an even higher priority and so at times both the built and the sound hardware of the dock displace, regardless of whether it is connected at home or on the road.
In addition to the audio data PulseAudio clients can also send additional metadata to the sound server, which are considered in the selection of the target device. So can be routed only through the headset, for example, the sounds of system messages always have the built-in speakers, music and the audio track of video over the respective preferred device, VoIP calls, however.
In addition to the exchange of devices and virtual devices, such as a combination of several physical or logical sound devices can be defined that can be used by client applications normally. For a screencast can be for example the complete edition of the PulseAudio sound pipeline plus the input of the microphone as a new input device (either mixed or as an additional track) create, from which can be taken individually without any problems, without requiring subsequent mixing or reworking. Linked to this, several channels can be synchronized without the clients themselves must implement the necessary waiting logic.
A fundamental problem with the audio output on Linux is that there is no clear stratification, but different systems services, or subsystems that access to the audio hardware, adaptations of sampling, mixing simultaneous audio streams, session management, access control, and advanced signal processing in an overlapping manner implement. PulseAudio takes the approach to combine a relatively large scope of services in a subsystem.
Coupling to the user's session
The Pulse Audio Server is not conceived as a system-wide server that runs independently of a user session, but the hardware like mouse, and monitor with the X Window display the user session is similarly assigned. For most desktop applications, this is desirable, since access to the audio inputs also allows in principle to listen to a system via the Internet, which can pose a significant safety risk. A configuration in the so-called "system mode" is possible in principle, however thereof - not recommended - both for reasons of security as well as due to serious technical drawbacks. This is in conflict with concepts where a media server such as Music Player Daemon is usually designed as a system service for direct access to the audio hardware, necessarily the complete audio data are transmitted without. However, it is possible to access PulseAudio services across the system via the network interface, wherein it has however not yet established an integrated and unified approach to the access control as it exists in the area of text entry, for example, the pseudo-terminal.
Network capability
By abstracting can use equally, without this requires additional programming effort PulseAudio client remote and local sound hardware. It is possible both that the local PulseAudio daemon lets the data to another, accessible via a network daemon, and that the client directly contacted another PulseAudio server on the network. Since a PulseAudio daemon is a way to access over the network to your physical sound hardware, must run on systems without hardware sound no sound server. Thus, in a network with a central audio devices, such as a home theater or in a studio, used by all systems of the same system, central sound server (but see below regarding access and security ).
Sound Filters
All audio data passes forced the PulseAudio daemon, which thus is a suitable place for the application of sound filters, especially since most of today's processors are able to perform similar calculations in parallel on multiple data sets.
The most important and most essential in the graphical user interface point is the ability to adjust the volume of each audio channel and each audio stream to configure each application individually (or mute ), even if the corresponding program for it does not own possibility. These settings can be saved and then stay for the application exist. In addition, equalizer functions can be used.
Not any sound hardware can process the same or even different sampling frequencies. Some applications generate audio streams with fixed sampling rates and also expect such as input. The PulseAudio daemon will take the necessary conversion before automatically and provides for different CPU-intensive algorithms. This is associated with a frequently occurring problem that a better quality but computationally intensive algorithm is preset ( resample -method in / etc / pulse / daemon.conf ).
Properties
On physical sound hardware PulseAudio support anything that supports each native sound system of the operating system. Under GNU / Linux, this is ALSA, OSS under BSD and DirectSound under Microsoft Windows. Each sound device is either source ( Source) or destination (sink ) for audio data. In addition, other, connected via the network PulseAudio servers and devices or processes that support the RTS protocol come into question. Even PulseAudio clients themselves can be both sink and source. However, many adapters only support their function as a source for the adapted process. PulseAudio has access to a Bluetooth audio device, even if the native sound system does not support them (as long as Bluetooth is widely supported).
The PulseAudio daemon provides the opportunity during the period to be extended by loadable binary modules. Most adapters and filters are implemented in this way.
The latency of most operations is very low and can be measured by the clients and influences. High latency can lead to embedded and mobile devices to energy savings, low latency is, eg for VoIP or multiplayer games required.
Within the daemons as well as local clients, the PulseAudio sound architecture is without the time-consuming copying of audio data ( zero-copy architecture ), however, this applies only limited in the use of adapters.
Due to the dependence on the access to the PulseAudio daemon for all audio functions of this is centrally controlled and automatically in the PulseAudio client library which beside the pure finding of a server offers the option of the preferred selection of several available. Unless off a server using Zeroconf in the network is automatically discoverable. Locally this can be done via D-Bus. However, adapters, especially the ALSA adapter, and PulseAudio clients can also start the PulseAudio daemon itself, if it is configured locally and not already running. X11 desktop environments usually do this automatically.
At the lowest level, two environment variables are necessary for access to the server: PULSE_SERVER and PULSE_COOKIE. These are evaluated by the PulseAudio client library or, if they do not exist, set. By default, the daemon is X11 - based session configured, that is, the variables are not set, the settings are entered when starting the daemons in the resources of the root X window and read by the clients there and can, for example, be " taken " from an SSH tunneled connection. Without the X11 session management access via the D-Bus can be obtained.
For the access control to the server PulseAudio handles the method of X11 and used for a pseudo-randomly generated "cookie", which is expected in PULSE_COOKIE, and by default from the file ~ /. Pulse -cookie of the user originates, runs under the account of the daemon. Normally PulseAudio is configured without this cookie is not possible to access the server locally, even if the process belongs to the same user as the daemon.