Ubuntu Wiki

Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.

• Launchpad entry: https://features.launchpad.net/distros/ubuntu/+spec/cleanup-audio-jumble

• Packages affected: esound, gstreamer

Summary

The idea is to make PulseAudio the default sound system on Ubuntu, replacing the Esound Sound Daemon (esd) and ALSA dmix. PulseAudio is a drop-in replacement for Esound, but adds new features, opening it for many entirely new areas.

Rationale

Apple managed to standardize on a single powerful sound system (CoreAudio) for MacOSX which makes almost all users happy, ranging from normal day-to-day desktop users to gamers, to professional audio people. We should be able to provide the same on Linux. PulseAudio can currently provide the functionality at least partially, with the only notable exception being pro audio. PulseAudio is a modular sound server, kind of an "application server" for audio. Beyond the obvious sound mixing functionality it offers advanced audio features like "desktop bling", hot-plug support, transparent network audio, hot moving of playback streams between audio devices, separate volume adjustments for all playback or record streams, very low latency, very precise latency estimation (even over the network), a modern zero-copy memory management, a wide range of extension modules, availability for many operating systems, and compatibility with 90% of all currently available audio applications for Linux in one way or another.

In the future it is expected that PulseAudio will extend to professional audio stuff, entering JACK's current application area. This however is not relevant for the implementation of this spec, at least at this time.

Use cases

• L. wants to play a video and a background music track at the same time, without any special setup and hassles but with lip-sync audio.
• L. wants to transparently playback local audio on a remote machine.
• L. wants to move the currently played back stream from the internal soundcard of his laptop to the USB headset he just plugged in, without any interruption in playback and with only minor clicking on the UI.
• L. wants the operation described in the previous item to be done automatically by the sound system if he plugs in his USB headset.
• L. wants to control the volume for each playback stream separately, selecting the right mixer track based on the song name.
• L. wants to merge his two stereo sound cards into a single 4 channel surround sound card.
• L. wants his MP3 music to always be played at half the volume but Ekiga's voice stream at the full volume level.
• L. wants to browse for the audio devices on the network and use them much the same way he already uses the shared network printers.
• L. wants to move the local audio stream which is played by his bedroom's computer without interruption to the computer in the kitchen.
• L. wants to multicast audio from his laptop to all machines in his network.
• L. wants mixed audio but still low enough latencies for voip.
• L. wants proper audio on his LTSP thin clients.
• L. is using an average-quality speaker set. It needs some equalization to sound right, however his audio player of choice (Rhythmbox :P) does not yet feature an EQ. He simply modifies the overall equalizer and everything that his PC plays now sounds good on his setup.

Scope

This specification changes the default sound daemon for Ubuntu. The same is immediately applicable to Xubuntu, if desired.

Design

Mode of operation

In order to provide the highest possible audio quality, use all features like hal support and dynamic stream handling, and not opening any potential attack vector, the upstream recommended mode of operation is to have a permanent pulse daemon running as the user, without automatic module unloading, and maintaining a permanent connection to the sound card hardware device. However, this mode breaks the following use cases:

1. Two users are logged in at the same time, and either of them wants to use the sound card.
2. Commercial and legacy applications often use OSS for sound output, which wants exclusive sound card access.

While 2. can be circumvented by calling the application with existing wrappers which redirect /dev/dsp access to the Pulse emulation, we recognize that we cannot enforce this at the moment. Thus the alsa sink driver needs to be modified to release the sound card file handle when it's inactive for 5 seconds.

Compatibility

PulseAudio emulates the OSS, ALSA, and esound API (amongst others), so that existing applications can be moved to Pulse without much effort. Just for the record, this emulation has nothing to do with ALSA's OSS emulation, Pulse will work even if these modules are loaded (but not used).

For fully transparent OSS emulation, we should check whether the FUSD userspace devices implementation is mature enough to replace the current LD_PRELOAD hacks.

GUI

PulseAudio offers three different graphical user interfaces for controlling audio (see a [http://0pointer.de/public/pulse-screenshot.png screenshot]:

1. pulseaudio volume control: Controls the volume of sinks, sources, and streams, and allows the user to move streams between sinks.
2. pulseaudio preferences: configure network related services including multicast
3. panel applet: notify about changes of sound hardware, choose default device, call the other pulseaudio tools.

The volume control and preferences applications are sufficient for all the use cases mentioned above. The panel applet is just "nice to have" for control freaks, so we should ship it, but not activate by default.

We will ship the pulseaudio volume control by default, since it is a very convenient interface to control the volume per stream. However, we will keep the default Gnome mixer applet (which controls the hardware mixer levels) for now.

Implementation

Code

• The esound package is not installed by default any more, and replaced by pulseaudio-esound-compat.

• The esound client library will still stay around to not break Gnome sound events and custom packages still relying on it.

• Upstream is working on a clean and generic solution for the sound card file handle releasing on inactivity, but this will not be finished before spring 2007. After discussion with upstream, we decided that we will create our own simple patch for this for feisty, which might not fit well into the clean pulse architecture, but allow us to deploy, test, and benefit from it now without losing legacy compatibility. [pitti: after some tinkering, it turns out that this is not possible; due to Pulse's design, the sound card is always active, pulse constantly sends silence audio data]

• Change gstreamer to prefer the pulse sink, and fall back to ALSA.
• Change other applications in main to default to pulse output, if there is an available output module (xine, mplayer, libao (for Gaim), xmms, etc.).

Data preservation and migration

Package upgrades will be handled through a transitional esound package added to Debian's pulseaudio source package (this will work because pulseaudio's version is higher than esound's). Data migration is not necessary.

Comments

• Beware that flashplugin-nonfree creates a /tmp/.esd folder in an init script. This prevents pulseaudio from starting. ("strace pulseaudio | grep -i open" or something like that) Work-around is to uninstall flashplugin-nonfree, of course, or disable the init script, which I think means flash sound will stop working, but I haven't tried. JackWasey

  • This has been resolved in Feisty's ALSA-based flashplugin-nonfree (there will be backports to dapper and edgy) that uses the latest beta 2 of Flash 9. The upgrade removes the initscript, so upon reboot, there will not exist a /tmp/.esd if you don't enable EsounD. ["DanielTChen"]
  • Furthermore, Gutsy's flashplugin-nonfree combined with a modified libflashsupport (to support PA) obviates any esd hackarounds. One item of concern is libflashsupport's possibly non-Free license. ["DanielTChen"]
• I have made trials in Edgy with the packages provided by Lennart : no gnome sound (miss post configuration), but every applications like Listen, Totem or Banshee are detected and works ; Xmms cna play music with the dedicated plug-in provided ; the jack-module is not detected, so impossible. [wiki:Ttoine ttoine]

• Why PulseAudio was not based on jack? Explanation is needed.

  • My guess is that jack was built from the start with pro audio work in mind, making it less suited for general applications. Anyway, pulseaudio seems more ready for the desktop than jack, so history is not really relevant. PeterVanDenBosch

• On the PulseAudio website there is an interesting page about [http://www.pulseaudio.org/wiki/PerfectSetup the "perfect" PulseAudio setup]. ProgFou

• Please note that the GUIs pulseaudio provides are high on geek crack, mentioning underlying libraries and tech jargon like alsa, hw:0, sinks, sources (monitor/virtual/hardware sources--what are these?), etcetera. This is not something normal users can easily understand. Rather than "alsa hw:0", brand and model of the soundcard should be displayed since they are recognizable by users. Don't include the current difficult GUIs by default please. PeterVanDenBosch

• On my system, I solved the problem with PulseAudio blocking the alsa device to other applications by connecting the audio sink and source to dmix:0 and dsnoop:0 instead of hw:0. Obviously this adds yet another layer of latency, but at least for me it isn't noticeable. On the other hand it makes legacy applications work perfectly, including 32-bit applications on amd64 which currently can't use PulseAudio via alsa because lib32asound2-plugins is missing. The dmix solution also avoids the inevitable race conditions which would occur with PulseAudio releasing the device only after a timeout. Even if the timeout is set to just one second, you will run into trouble if clicking the menu item to start a legacy alsa application also triggers a sound event. -- DanielElstner

  • In the "Perfect Setup" (see above) it is recommended to setup default ALSA devices (pcm.!default and ctl.!default) to go through PulseAudio, and of course make PulseAudio use direct references to ALSA hardware devices, to not loop between ALSA and PulseAudio. -- ProgFou

    • Yes. But connecting the sink explicitly to dmix:0 and at the same time having default routed through PulseAudio does not introduce a loop. It works perfectly here. Of course having pcm.default go through PulseAudio means that legacy applications which don't work through the alsa->PulseAudio binding cannot use the default audio device. The device plug:dmix:0 can be specified directly in order to bypass PulseAudio. But it would also be possible to set up an alias name (maybe "direct"?) for that purpose.

  • This proposal does not (and cannot) resolve instances where a knowledgeable user specifies an explicit virtual device that is not dmixed or dsnooped, e.g., hw:X{,Y} (or any extended ones like plughw:X{,Y}, plug:surroundfoo, etc.). This limitation applies to the core ALSA implementation and cannot be bypassed consistently. Arguably this concern lies outside the common desktop use cases; need more input from Ubuntu Studio considerations. ["DanielTChen"]

CategorySpec