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?

2 Answers 2


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 - 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 a source-based distribution like Gentoo - you might get mixing problems. Pre-compiled applications that distros ship are usually only built with support for Pulseaudio, not pure ALSA. Ubuntu for example prefers PulseAudio. It comes with PulseAudio by default, so every application is compiled to only use PulseAudio.

PulseAudio does have its benefits. People say that it is good for working with audio across a network, and it solves some issues with multi-channel audio streams that happened under pure ALSA. It's also supposedly easier to develop apps for PA. On the end-user side of things, it's easy to select new devices, to control volume by app, etc.

However, in the default configuration it adds a not insignificant amount of latency into the mix. This is a big con for certain types of tasks that require low latency like some games and software.

OSS is an alternative to both of these, but it's not licensed under the GPL, which makes it not likely to see a lot of adoption by distros.


Typical PulseAudio-powered sound systems, like Ubuntu:

  • Kernel: ALSA -> Userland: PulseAudio -> app1, app2, app3
  • In the typical Linux system, PulseAudio mixes audio from all your different apps and feeds them up the chain to ALSA.


  • Kernel: ALSA -> dmix -> Userland: app1, app2, app3
  • With just pure ALSA, you need dmix to mix multiple apps. Without it, ALSA can only play an audio stream from one app at a time.


  • Kernel: OSS -> Userland: app1, app2, app3
  • With OSS, the userland apps talk directly to OSS in the kernel, which mixes the streams itself.

So to sum up, in your typical system these days, ALSA talks directly to your sound cards, and Pulseaudio talks to your apps and programs and feeds that into ALSA.

  • 2
    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 say...do you want an easy linux environment to play music? Are you thinking about the new UbuntuStudio? Well, think again... :D
    – dag729
    May 24, 2010 at 12:40
  • 7
    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.
    – Apache
    May 24, 2010 at 15:24
  • 3
    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... May 24, 2010 at 17:14
  • 2
    Avery: It supports unloadable modules now. So if it crashes, it'll simply reload the module for the graphics adapter. But as far as I know they are still modules. (Not running in the userspace.. that is unpossible). | About SDL: It s..ks. Every game writer complains about it because it gives slow performance, complicated problems, etc etc. (I won't list them, check through a search.) Even the open source transport tycoon is slow with SDL.
    – Apache
    May 24, 2010 at 17:39
  • 3
    @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. Oct 15, 2014 at 7:32

ALSA talks right to the sound card and can only handle 1 app.

However, Pulseaudio, when installed, is that 1 app that ALSA is handling, and pulseaudio takes audio data of ALL apps and then feeds that to ALSA

Here's a flow:


USERLAND: app1, (app2, app3) -> ALSA -> SoundCARD.

The reason app2 and app3 are in () is because ALSA is not handling them.


USERLAND: app1,app2,app3 -> PulseAudio -> ALSA -> SoundCARD.

However, OSS is different.


Userland -> Kernel -> OSS -> Sound Card

OSS does the mixing it self.

Hope it answers the question!

  • 1
    How is this better than accepted answer?
    – Toto
    Jun 16, 2022 at 16:54
  • 1
    @Toto it is easier to understand
    – Velcro
    Aug 9, 2022 at 20:03
  • The arrows in the accepted answer are backwards, and lead to confusion.
    – wheeler
    Oct 12, 2022 at 19:41
  • @wheeler oh yea... about that
    – Velcro
    Nov 19, 2022 at 10:28

You must log in to answer this question.

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