Some time ago, Mandriva decided to install the PulseAudio sound server by default in its distribution. Personally I did not really like the decision to activate PulseAudio by default in all desktop environments: I have been using Alsa with great satisfaction now for years, and I did not have any problem with that, so having to depend on yet another service did seem overkill to me. Nevertheless, I let PulseAudio be activated on my system too, in order to help as much as possible with bug hunting.
I think this was very useful, as I could help debugging some problems which are now fixed already or will probably be fixed soon, like some policykit related problems, problems with libao applications and pulseaudio, an amsn crash due to a bug in pulseaudio’s oss wrapper, some PulseAudio menu entry fixes, suggestions about the the default choice of PulseAudio applications installed by default.
PulseAudio has improved a lot during the last two months, and it’s sure that Mandriva’s current implementation will be a lot better than what was shipped in Fedora 8. Still I am not conviced at all it is a good idea to activate PulseAudio by default like will be the case now, and I have decided to remove it from my system.
To explain why, let’s first take a look at the advantages which PulseAudio claims to offer:
- Sound mixing: different applications can produce sound at the same time without any problem. I have been using Alsa for years now, either with sound cards which support hardware mixing, either with Alsa’s dmix software mixing. I’ve never had trouble playing different audio streams at the same time with this set up.
- Moving sound streams between different audio cards. I only have one sound device, so I do not need this feature. This feature could be handy for people using headsets for VoIP application, because they can move their VoIP application to the head set, and keep their music player on the normal sound card. I am not sure a sound server is really needed for that: I would expect VoIP applications to have a configuration panel where the user can change the audio device to use.
- PulseAudio makes it possible to set different volume levels for all applications. Most applications today already use their own internal volume mixer like for example Rhythmbox, Amarok, Totem, Kaffeine, Pidgin,… Because of that, I have never felt the need to use this PulseAduio PulseAudio feature during these months, and I doubt even lots of users will know of the existence of this possibility.
- PulseAudio does higher quality resampling than Alsa for sound cards supporting only 48Khz output. I have such a sound card, and did some listening tests with headphones. I could clearly hear a difference between PulseAudio’s low-quality “trivial” resampler and its better “speex-float-1 resampler”, however I could not hear a difference between PulseAudio’s higher quaility “speex-float-3” resampler and Alsa’s resampler: both sounded good to my ears. I did not really find any reliable listening tests proving that Alsa’s resampler is bad, only some vague claims.
- PulseAudio makes it possible to send sound over the network to another machine running PulseAudio. Without any doubt, this is a great feature for thin clients, but this feature is only used extremely rarely on normal desktop systems.
So I did not find any advantage in using PulseAudio. Still, the potential features could be interesting and make it worthwhile to keep PulseAudio nevertheless, one never knows these features might become useful one day? No. For me there were too important disadvantages when using PulseAudio:
- PulseAudio’s resampler uses a lot of CPU time. (Mandriva bug #36084). On my not too slow Athlon 64 3500+ CPU, PulseAudio was using more than 7 % of CPU time when playing music with the default resampler. Choosing the lower quality resampler speex-float-3 made it use still more than 3 %, which is still a lot on such a CPU. Rhythmbox itself also seemed to use more CPU time when using PulseAudio than when using Alsa. There is clearly a lot of optimization to do here. The only reaction by PulseAudio’s developer is that MMX/SSE/SSE2 optimization patches are welcome…
- PulseAudio forces every application to use PulseAudio. When PulseAudio is activated, other applications cannot access the sound device directly. Alsa applications are routed through PulseAudio with a libalsa plug-in, OSS applications with the padsp wrapper. As the libao bug shows, this is still not working like it should. Even KDE’s Arts sound server output is routed now through the PulseAudio server: that means KDE 3 users will enjoy running two sound servers at the same time! Not only are there still difficult to debug interaction problems (known by Fedora for months, but unresolved), but it seems clear to me that this has to introduce extra latency for audio applications. In the Windows world, there are different professional studio applications which require very specific sound hardware. How could such applications benefit from minimum latencies and other advantages of these hardware, if they cannot access it directly, but have to pass through PulseAudio?
- PulseAudio stops all sound if you switch to another console and/or switch to a different user. If I switch from X to tty0, there is no reason why PulseAudio should mute all my audio applications. In the end it feels like PulseAudio prohibits me to use tty0 and thinks that I should use an X terminal instead. I don’t like being forced to change my behaviour. If I want to stop my music, I will really do so myself, there’s no need to decide this for me.
Looking at PulseAudio’s timeline I currently have the impression that not much development is happening anymore, but instead the developer spends his time writing a rant about Alsa.
In the end it feels like PulseAudio could be a funny toy for geeks who want to tinker with their sound system, but for someone who wants things to just work without too much hassle, Alsa still feels much better. That’s why I removed as much PulseAudio packages as possible. All my sound applications are again using Alsa now. Everything is working fine, and I feel freed from a service which was only causing me needless trouble. In the end, I think the most problems which PulseAudio tries to solve, should have been fixed in Alsa instead of developing a complete new sound server.
Update 23 January 2008: It seems some people consider this post as a “rant” or as “bashing”. Personally I have the feeling this is not a completely fair judgment: I tried to clearly give objective facts for why I do not like PulseAudio, while “ranting” or “bashing” is much more negative and is much more about feelings than about real facts. It should also be clear that I would consider PulseAudio acceptible if it its resampling did not use so much CPU time as it does now, and if it was not so invasive, but let applications still use Alsa directly, like in fact Arts and Esd always have been doing.