Releases/FeaturePulseaudio

Pulseaudio

Summary

Use pulseaudio as sound server, install and use it by default.

Owner

• Name: LennartPoettering

Current status

• Targeted release: Fedora 8
• Last updated: 2007-10-02
• Percentage of completion: 100%

Pulseaudio packages are available, but not installed and used by default.

Needs support in other packages so that PA support is properly set up using padsp, the alsa plugin and stuff.

The Pulseaudio and hal packages in rawhide now have the necessary support to play well with fast user switching.

The alsa-plugins-pulseaudio package has just appeared in rawhide.

PulseAudio has been made default for new installs.

The switch has been officially anounced

Usage cases/rationale

1. Karl logs into his system. He has desktop sound effects turned on, so it clicks and plings as he presses buttons and does other things. When he listens to music in rhythmbox, the clicks and plings do still happen over the background music.

2. Karl wants to quickly check out another song that he knows how to find in xmms, so he turns down the volume in rhythmbox and starts xmms. He hears the music from both players at the same time.

3. Karl shares his desktop with the rest of his family. His wife Sara uses the user-switching feature on the lock dialog to start her own session. The music from Karls session stops when Saras session becomes active, and the flash ads on the web pages she visits make the expected noise.

Scope

This requires changes to Pulseaudio to cooperate with ConsoleKit or hal. It also requires changes to the configuration of legacy audio systems to make all sound go through Pulseaudio.

Test Plan

Verify that the use cases above do all work. Also test that a11y tools which use sound (ie the orca screen reader) work with pulseaudio, both inside the session and on the login screen.

Dependencies

Depends on a ConsoleKit or hal enhancement to notify interested applications when sessions become active or inactive.

Details

Fast-user-switching support

After some discussion, the current plan is to make hal emit dbus signals when it adds and removes ACLs on devices. Pulseaudio will then let go of the device. Later on, if the kernel gets revoke() support, hal can enforce this. Pulseaudio should be prepared for that and handle SIGBUS when using mmapped devices.

Current HAL development version support the ACL changes now, and the Pulseaudio snapshot in rawhide makes use of it.

Basically, FUS works fine now.

revoke() is not available in the kernel yet, support for this I will leave for later.

Legacy audio systems

Most important are OSS and ALSA (though I wouldn't call ALSA "legacy"). The former can be supported using padsp in most cases. padsp has to be run for each program seperately. I am not sure how can do this best. Suggestions welcome. I fear every single OSS-using package needs to patched to replace the actual binary by a shell script that runs the real binary through padsp. The latter can be supported through the alsa-plugins package which is currently being introduced to fedora CVS and should be very straightforward.

The gstreamer-plugins-pulse package should probably installed by default as well.

We also have plugins for XMMS, libao and a couple of other application which are probably very low priority, and are mostly not even part of fedora yet.

Packages

Here is a list of packages that will be needed in the default install:

pulseaudio
pulseaudio-esound-compat
alsa-plugins-pulseaudio
pulseaudio-module-x11
pulseaudio-module-gconf
pulseaudio-utils
gstreamer-0.10-plugins-pulseaudio

Also, newer flash needs some support library to work with pulseaudio, that we probably want to install by default (since firefox will happily offer to install flash, and it is nice if sound works after that).

We also need to remove esound from the default install.

Contingency Plan

Stay with esound/no sound server at all. None of the above scenarios will work.

We can always go back to the status quo ante easily. It's just a matter of having pa in the default install set, toggling one gconf option, and patching a single config file (asound.conf). Since PA is a drop-in replacement for ESD, which even comes with an "esd" script (which is command line compatible with the original ESD), changes necessary are not too invasive.

Comments

• BastienNocera: See also the use cases I sent some time ago to the Utopia list, especially Rosario's, which should directly apply here.
• KevinKofler: Aren't those use cases already a solved problem with ALSA's mixing support (both hardware and software (dmix))? 1. and 2. work perfectly for me already with pretty much any app except for those which either still use the old OSS /dev/dsp interface or insist on using ALSA hardware devices only. In both cases, a sound server isn't going to help, just make things worse (because it stops those apps from starting up or outputting sound at all). Luckily, it's often possible to force /dev/dsp-using apps to behave using aoss, and to force ALSA-using apps to use the default device even if they don't default to it (which is broken, it's called "default" for a reason!). And no, my sound card doesn't support hardware mixing, but that's what dmix is for, and the "default" device automatically defaults to dmix. If it doesn't for some cards with no hardware mixing, then that's the problem to solve, it's no use papering over it. As for 3., that's just a matter of setting the correct dmix IPC permissions (which has to be done for the sound server too, it has to do IPC too). The only problems a sound server solves are i. legacy apps which want a very specific sound server and refuse to run or output sound without it (solution: just let them use that sound server and make sure that sound server outputs to the default ALSA device) and ii. network transparency (which is nice, but irrelevant for the single-machine use cases described here). There's a reason KDE is dropping aRts in KDE 4!
• LennartPoettering: Firstly, dmix is buggy and also unusable if you care for latency. Secondly, PulseAudio does much more than dmix ever did. It allows you to seperately change the volume for each stream you play back, it allows you to transparently move streams from one device to another without interrupting the stream, and the list goes on and on and on. PulseAudio is not just a simple sound server in the style of esd, arts or whatever. Instead it tries to be "an application server" for sound, a "compiz" for sound and a lot of other stuff. You might find my talk at LCA interesting which tries to explain that: http://mirror.linux.org.au/pub/linux.conf.au/2007/video/talks/211.ogg, http://0pointer.de/public/pulseaudio-presentation-lca2007.pdf.
• KevinKofler: I'm afraid I'm still not convinced. For one, dmix works fine here, and secondly, if it's buggy, why can't it be fixed? As for latency, that's the case with all mixing sound servers (you obviously can't do software mixing without introducing latency). And setting the volume for each stream is something which should be done in the application, and existing apps already have their volume settings there. However, I see that you do have an ALSA plugin to make PulseAudio work like dmix. But why is it "not recommended"? IMHO, doing things the way dmix does is the right way, apps use ALSA, and they get hardware mixing if available, and whatever software mixer currently works best, be it dmix, PulseAudio or whatever, transparently. (Ideally, even network transparency should be handled that way, is that already possible with PulseAudio's ALSA plugin?) And worst case they can always get an unmixed hardware device if that's all that's available, that's better than nothing. By the way, I think this Wiki page is the wrong place for a lengthy discussion like this, maybe we should move this to the fedora-devel-list?
• ChrisMohler: I see PulseAudio and LTSP seem to work better together than ALSA and LTSP - something to consider during the implementation.
• Yepp, the thin client people are PA's best users right now as it seems
• ChrisTyler: PulseAudio could solve many audio issues on multiseat systems -- we need to keep that use case in mind when working on the fast-user-switching policies in ConsoleKit.
• PulseAudio is not necessarily a good tool for sharing between sound devices between users, because of secuirty. Also, as far as I understood, it would be preferable to consider sound devices much like keyboards and mouses as devices that are not shared between seats. I.e. In multiseat systems for each seat you want to add your own pair of usb-boxes too, if you want audio (or probably usb headsets...)

---