That’s a very common question as of lately, and somehow I feel like most people who haven’t dealt with ALSA in the past would find it very difficult to properly answer to it. Even myself I would have ignored one particular issue till last night, when I hit another reason why I want to keep PulseAudio as my main and only audio system as soon as possible, reducing direct ALSA access.
With modern systems you mostly get onboard sound cards, rather than PCI cards and similar, unless you’re somewhat crazy and want a proaudio card (like I did) or a Creative card (not yet sure what’s the fuzz about that). To be honest, my motherboard really does have a limited soundcard so I would have needed a PCI card anyway to get digital S/PDIF output, and I want S/PDIF because the room has too much electric noise to the point I can hear it on the speakers.
Somehow, ALSA seem to hide to most users that there are indeed a lot of limitations with the HDA hardware. This because the idea for the HDA was probably to shift as much work as possible into software space rather than doing so in hardware; this is why you need a driver fix for the headphones jack to work properly most of the time. While this can be seen as a way to produce cheap cards, it has to be said that software always had to compensate for hardware defects since it’s more flexible. And having most of the processing done in software means that you can actually fix it if there is a bug, rather than having to find a workaround if anything.
So, no hardware mixing, and ALSA has to use dmix, no hardware volume handling, and ALSA has to use softvol, no hardware resampling, and ALSA has its own resamplers, and so on so forth. But while ALSA has to cope with doing these things in the same process that are doing the audio output, and thus is not so good at coping with different processes accessing the audio device with different parameters.
Having a separate process doing the elaboration does not mean that you add more work to the system, you can actually make it do less work if, for instance, you ask that process to play a (cached) sound rather than having it opened, converted, and played back.
At the same time, the fact that PulseAudio handles mixing, volume and resampling in software does not mean that it adds to the work done by the software for most cards, since the most common cards nowadays, the HDA-based ones, already do all that in software, just you don’t see that explicitly because ALSA do them in process.
In my opinion, ALSA is really doing way too much as a library, since each time you open a device it has to parse a number of configuration files, to identify which definition to use (and even then, by default they are far from perfect, for instance for the ICE1712-based cards, which depending on the way they are wired may have two, four, six or eight channel outputs, the definition only suits the 8-channel model, and does not make sense with the lower end cards). And once it found the definition it has to initialise a number of plugins, internal or external, to perform the software functions.
And this is all without putting in the mix the LISP interpreter that alsa-lib ships with (I’d leave to Lennart to explain that one).
So if you think that PulseAudio is an over-engineered piece of software that performs functions in software that should be done in hardware, you better be a FreeBSD user. At least there the OSS subsystem does not try to do all the things that ALSA does (and on the other hand FreeBSD is trying to go the Microsoft way for the HDA cards, implementing the UAA specifications rather than having a huge table of quirks; as far as I can see that would be quite useful, if it’s going to work that is).
But even in that case you should probably find PulseAudio a good thing since it tries not to be Linux-specific and thus would allow for performing all the needed functions with a single cross-platform software without having to reimplement it in platform-specific systems like OSS or ALSA. That was my main reason to look into PulseAudio when I was working on Gentoo/FreeBSD.
For everyone who cares about users, let’s try to work all together to make PulseAudio better rather than attacking Lennart for trying to do the right thing, okay?
I understand why people hate it, it’s ugly at times, but what else can help me forward my audio over tcp, seamlessly? 🙂
Diego, as always a great article. Thanks for giving me so much details about ALSA and doing the first good post in this pulseaudio saga. Most people bash pluseaudio without knowledge of the details. Lennart can’t answer this without taking it personal because most bashing is personal, too.I’m happy that you are writing this article giving good reasons to use pulseaudio and not just saying “pulseaudio is better” or “pulseaudio fixes all the problems of the past”. Thanks so much!
One doesn’t need to be a FreeBSD user to use OSS. I use it and it proved to be way better than ALSA in all aspects.
Yes, let’s make PulseAudio better. Start with a CoreAudio output module so that PulseAudio works on nearly any/every conventional Desktop/Laptop system!!:>
Couldn’t something nVidia’s CUDA and AMD’s CAL be used in order to make GPU do the computing work in ALSA ?What’s more interesting, many boards have built-in on-board GPU which is not otherwise used.Phenom’s middle class boards, based on 780V and 790GX chipsets seem ideal for this…
I have a USB audio headphone, and with PulseAudio I may plug/unplug it without skipping a beat, I just mute/unmute the onboard sound.
Um, Pulse Audio is a software layer that rides on top of ALSA. Therefore, it _cannot_ be better than ALSA because it actually uses ALSA to output to the sound card.Pulse Audio is crap, and totally unnecessary.
Diego,You are right that PulseAudio can be improved. However, for me, PulseAudio is already good enough. I don’t use it only because of bad but unreplaceable applications that make assumptions that are valid only for dmix.E.g., by default, linphone has a list box in the device selector. So I either have to use the global “default” ALSA device, or “default:X” where X is the card name. So, there is no way to say “play ringtones through PulseAudio, but they should go through a different card than speech”.PulseAudio will become usable only when all ALSA specific fixed-choice list boxes pre-filled from /proc/asound/cards disappear from UIs of all applications.
Can somebody tell me that ssh is no better than TCP because it uses that to send packets? Please so just we know the idiocy of such a statement?@Branko: I sincerely don’t know how feasible it would be to use the GPU to do the work, but even if it was, it doesn’t really matter, since modern CPUs can do it just fine, it’s the way ALSA tries to do the work that is approached from the wrong side.@Alexander you _can_ workaround the use of default by using the ALSA PulseAudio plugin (that re-routs ALSA to PulseAudio and back again). But as you notice it cannot separate the tones from the conversation.At the same time, without implementing PulseAudio by default in distributions we’re not going to have upstreams who care about PulseAudio, which is the usual chicken and egg problem.
mhh ecco perchè la riproduzione della musica con il mio vecchio AthlonXP + Creative Soundblaster Live! la riproduzione audio prendeva molta meno CPU in %, del mio nuovo core2 + HDA intel…e comunque, sta storia che se sia meglo implementare di più in software che in HW, perchè permette di risolvere i bachi senza ricorrere a workaround, non mi piace!Secondo me, come dice anche Linus (in altri contesti) bisognerebbe essere semplicemente un po’ più attenti: del resto le schede audio le fanno da decenni, non dev’esser così difficle riutilizzar schemi collaudati e funzionanti e magari migliorati, mantenendo lo stesso il costo basso.sti bastardi… fanno le schede audio che di audio hanno solo l’attacco dei jack.. 😀
@Flameeyes:Modern CPU have the horsepover to do the chores, nbut they don’t always have the time. IOW, they tend to work best when they do as little task switching as possible and with as big batches as possible.Which aint really sweetspot for soundsystem. There you have small buffers that have to be re-filled relatively frequently.If GPU does that, then CPU doesn’t have to worry so much about worst-case response time etc.
There is another issue here and its critical. Alsa will have to solve lot of problems pulseaudio does in time in kernel interfaces.Its called containers. The means to run many distributions side by side.Focus on pulseaudio does not address the issues running containers are going to cause. How many process ID sets do you have. Answer is unlimited. Containers change a lot of rules.Pulseaudio is basically masking over something that need low level work. Pulseaudio multiable volume controls and everything else needs to be kernel linked.
I’ve used it… Mainly because of avahi support. I had a full 5.1 setup, with an avahi-exported virtual 2.0 and 5.1 card ontop.The phatt sound is just a click away. There isn’t anything more beautiful than an autoconfiguring home setup :)This is truly something that will never show up in alsa-lib, for good reasons…
The one thing that convinced me to try PA is the network part, but trying to get it to cooperate with the version of mplayer on a default Xandros eee – horrible. It was skipping like trying to play vorbis on a 386.You’ve just about convinced me it’s worth trying again, now that I’ve got a real OS on it…
Maybe people wouldn’t hate PulseAudio so much if it weren’t shoveled onto us in a non-working condition with a shitty inscrutable interface.
Hey ,thanks for putting up this article.the pulseaudio haters ,most of them ignorant of the fact that pulseaudio runs atop over ALSA ,must read this.I found it very useful to convince anti-linux yawners.Thanks again!.
the problem i had with pulseaudio, is having perfectly working sound prior to its implementation with pure ALSA, to only having sound in one application at a time, followed by pulseaudio locking up the soundcard so no apps can use it, pulseaudio is a wrong solution to the wrong problem, sound servers are a terrible idea.
I don’t hate Pulseaudio, I just hate the fact that it breaks functionality of my applications at every single upgrade.It should be tested and developed by that part of the community made up of specialized users that actually need it and use it before being imposed on the rest of us who, for the time being, want audio that just works.With Ubuntu 9.10, unlike 9.04, the removal of PA creates havoc. This has been admitted as a design decision. Come on!!!!
Interesting that you should mention the ICE1712-based cards like the M-Audio 24/96, a very common card and has been on the market for many years. I have never had any problems getting ALSA to recognize and use this card. On the other hand PulseAudio as packaged in Ubuntu does not. It requires writing config files to even be recognized by PA.To me pulseaudio in Ubuntu has never given me anything but trouble and I wish it would just go away.
I’m interested in installing PA. I have the Audiophile2496 card and I too have not been able to get it to work in Ubuntu (9&10). Can anyone tell me whether the procedure in the Gentoo wiki of PA works with the ICE1712 cards?
if it wants to be the X11 of audio then release it under an X11/MIT license. the problem I have with pulseaudio is that *everything* (even terminal apps) now seems to link to it and/or require it and this makes it impossible to turn it off or even it it is installed just make it *not run*.