Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

While trying to get my sound to work, I was wondering about the roles of ALSA and PulseAudio. I have both installed and was wondering, for example, which of them needs to know about my sound card.

Both seem to be able to use each other, there's a pulseaudio plugin for ALSA, and on my system, alsa shows up as a sound card in pulseaudio.

Which of the two does what, are they alternatives or complementary?

share|improve this question
up vote 16 down vote accepted

ALSA is the kernel level sound mixer, it manages your sound card directly.
ALSA by itself can only handle one application at a time. Of course, there is 'dmix', which was written to solve this problem. (It's an ALSA module.)

PulseAudio is a software mixer, on top of the userland (like you'd run an app). When it runs, it uses Alsa's channel - without dmix - and manages every kind of mixing, the devices, network devices, everything by itself.

In 2014, you can still run only ALSA. But unless you compile your applications for yourself and enable ALSA support everywhere - or use Gentoo - you might get mixing problems. Because pre-compiled applications that distros ship, always have a preference. Ubuntu for example prefers PulseAudio. It comes with PulseAudio by default, and every application tries to use it as well.

Whats the point? People say for networking it is good, and it solves the multi-channel misery. It's also easy to develop apps for PA (so they say). It's easy to select new devices, to control volume by app, etc etc. However, it adds latency as it runs in the userland.
This is a huge minus for gaming, for example. Even in 2014, you cannot use PulseAudio for competetive gaming on Linux. Not that it matters anyway. Even Valve abandoned Linux.

OSS would be a great alternative. But it's not GPL, so no way it's ever going to be a default, or become popular or anything.

Typical sound system nowadays, like Ubuntu:
KERNEL:{alsa} -> {alsa-channel} -> user:{pulseaudio} -> user:app1,app2,app3
Simple ALSA:
KERNEL:{alsa} -> dmix (it "runs in the kernel") -> user:app1
ALSA with dmix (e.g.: can handle multiple apps at once):
KERNEL:{alsa} -> dmix (it "runs in the kernel") -> user:app1,app2,app3
KERNEL:{OSS(module)} -> user: app1,app2,app3

share|improve this answer
Actually, everytime I found Pulseaudio I found PROBLEMS! Funny thing is that it seems (at least based on my experiences) to have problem also with the RT version of the kernel, that is to you want an easy linux environment to play music? Are you thinking about the new UbuntuStudio? Well, think again... :D – dag729 May 24 '10 at 12:40
There is an rt (daemon) argument for PA, try launching with that. You have to add your user to "pulse-rt" group (at least on Arch) in order to be able to use it like that. Well. For Audio studio stuff, use JACK audio connector. (Jesus... a new system again? :)) Or stick to OSS. – Shiki May 24 '10 at 13:33
Oh don't think. Graphics are also a pile of.. Linux is NOT for desktop use to put it simply and bluntly. Xorg is a X server so you basically start a SERVER and you WATCH it (what a nonsense? yeah). On MAC, Windows, Haiku, GUI runs from the kernel (okay its inside the kernel). Well. It would make sense doesnt it? Also, there is no native interface. Like on Windows, Windows.Forms. On MAC Cocoa. Here, you can only use FAT toolkits, like GTK, Qt.| Network is agreed, its in kernel, its OK (okay if the manufacturer provides good driver like Intel does)... so thats it. – Shiki May 24 '10 at 15:24
On MAC, Windows, Haiku, GUI runs from the kernel (okay its inside the kernel). Well. It would make sense doesnt it? Actually it doesn't. Remember the bad old days of "NT 4 video drivers that crapped out the system"? Yeah, that's what caused it - running crappy drivers in kernel space. Why do you think Microsoft suddenly went all up-in-arms about getting signed drivers into Windows? Bingo! Because crummy drivers were causing system crashes. Getting them signed meant getting them vetted, and a smidgeon of QA goes a long ways... – Avery Payne May 24 '10 at 17:14
@Skiki - I realize the answer is outdated now, but can you please provide references where Valve has abandoned Linux? Far as I can see they're still going ahead full steam, mind the pun. – aggregate1166877 Oct 15 '14 at 7:32

PulseAudio is a great idea which fails dismally in reality.

ALSA when configured correctly works very well and reliably.

Linux as a Desktop, frankly when you think before buying any old junk to build your workstation, Linux delivers as good if not much better than Mac OSX or Windows 7 / 8.

I have used all of of the OSes and before Windows was, Unix, won't use Ubuntu (flaky, with some nice tools and lots of bad bleeding edge crap, fork of Debian).

My setup: Debian 7 64bit KDE, ALSA=>dmix as the host running VirtualBox to host the guest VMs and to run my businesses.

  • Debian 7 XFCE for most virtual Desktops. (One with pulseaudio so I can use Skype - now a pile of steaming crap.)
  • Centos 6.5, 64Bit and 32Bit Gnome and KDE VMs.
  • Windows 7 & 8 64Bit & 32Bit VMs
  • Apple OSX 64bit as a VM.

I run multiple sound applications across multiple sound cards concurrently without any issues, it would be nice if low latency network sound could be built into ALSA, but pulseaudio is far from acceptible.

My 20cents worth.

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .