Bye Bye PulseAudio

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.

22 thoughts on “Bye Bye PulseAudio

  1. Well that’s a shame that you’re not enjoying Pulse Audio as I love the features it gives me.

    I agree that working with arts is a pain but as everyone knows arts is dead in the New World Order of KDE4 and both the xine and gstreamer backends of KDE4’s Phonon have direct support for pulse (although xine’s could use some TLC I admit).

    I find it interesting to see how people continually express annoyance that they need a “sound server” and then extoll the virtues of Alsa’s DMIX without really appreciating that DMIX *is* a sound server. It’s just one that is internal to Alsa and not a separate process. I wonder if people would care as much if pulseaudio had just been a drop in replacement for DMIX (e.g. spawned automatically by Alsa just like DMIX is)? Everyone would probably love it then – just great new feature improvements for DMIX!!!

    It’s also odd that people keep talking about how Apps should do X and Y (e.g. the app should implement a volume control, the app should implement a method of detecting audio devices and moving streams about, the app should provide accurate latency calculations for video sync timing etc. etc.). This is not a good design which evern way you cut it. Sure it’s how things are done now, but why make apps go through multiple hoops to implement features that can instead be implemented in one place? I admit the UI of some of the pulse utilities could do with some TLC etc. but I’m sure they will get better over time. Surely a single place to control volume and switch streams to other devices is far better from a UI perspective than burying the exact same options, called different things, inside different menu/dialog structures in different apps?

    As for the user switching thing, this is IMO a great improvement for numerous reasons. Switching to a different X session works *exactly* how it should as I’m sure you’ll agree. If you don’t like that switching to a tty causes the last X session to have sound privs removed, then this is not even a pulse issue, it’s a console-kit issue. console-kit is responsible for removing access to the sound hardware for the inactive session.

    And finally on my list for the anti-rant :p is the network control. I’ve been waiting for good network control for *years*. I work in a small office and we like to play music in the office (only creative commons stuff for licensing reasons…. honest!). Sometimes it’ll be me that plays the tunes, other times it will be my colleagues. Either way, we can all share the sound system with the big amp and speakers without a crazy setup of cables that also mess up our local sound system. I also use this on my laptop at home to my home media system. It’s awesome! So while thin clients definitely benefit as you say, it’s of wider use/interest too.

    I can see why some of the things pulse is good at doesn’t interest you but I hope others are not put off exploring what it can do! With some of the funky plugins that will no doubt crop up in the future for pulse it will only get better!

  2. “I think the most problems which PulseAudio tries to solve, should have been fixed in Alsa instead of developing a complete new sound server.”

    Alsa is in kernel space, and I do not think we could and should push everything in kernel. More ever, I do not see why we developped alsa when we could simply improve oss :)

    “PulseAudio forces every application to use PulseAudio”

    The same goes for alsa and almost everything, afaik.

    Regarding pulse and X, I think this can be configured. of course, there is people that want this and the contrary ( ie some people want to be able to listen to music when switching user, and some that do not want ).
    Maybe we could have something like “if there is 2 users with uid > 500, then implement the mute when user change stuff” and do nothing when there is only one user.

  3. I do agree with Frederik.
    Whereas PulseAudio is very usefull for thin client, and eventually network sound ( maybe DAAP is a better solution ), for everything else pulseaudio seems to be overkilled.

    Michael Scherer> ALSA was developped instead of OSS because OSS in Linux was an implementation of proprietary OSS. However the Linux OSS was lacking a lot behind the commercial one.
    However IMHO there’s still many issues with ALSA and notablyè its API as ALSA seems really overkilled and not very efficient to hide things or provide common features to all sound cards and in a transparent way : ALSA could be improved IMHO.
    The same also for V4L2 ( seems to be very hard to develop a webcam driver using V4L2 and for which you don’t need to apply quirks/hacks ).

    Colin Guthrie> Frederik is not saying that everything should be develop in kernel space inside ALSA. It’s just that “Sound mixing” should be done transparently at ALSA level.
    I’m still using PulseAudio to see how the situation is improving and because I’d rather have a cooker box close to the future release, however there are some very annoying bugs like Amarok which stopped working when trying to listen music a second time, or mplayer no longer working.

  4. “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.”

    A lot of people trying to get sound from both TeamSpeak and any Id software game do have this problem without hardware mixing.
    Some of them find a solution, but most end up with artsd (and its high latency) or go back to windows.
    I’ve even seen someone complaining about the same issue with warsow and mumble (both use alsa).

  5. Sylvain L.> Most of the time theses games use the OSS API, and unfortunately the OSS comptability layer is not compatible with dmix and sound card sharing. Fixing snd_pcm_oss would hve been the right thing to do

  6. would you care to give a small howto as if i try to uninstall pulseaudio the deps make it brings many others packages down with it…

    For me PA is nothing but trouble, it’s hard to find any good argument to keep a software that eats 20% to read an ogg where it was 5% before.

  7. Think about this:
    A user is playing a movie in his favourite movie player and wants to set the volume of his movie louder, but not the sound of his IM application still active. In the current solution, the user just adjusts the volume in his movie player, and that does exactly what he wants. In the Pulse solution you propose, the applications would not have this functionality and the user would have to start another program to adjust the volume in his movie player. Now that’s not what I call intuitive…

    Preventing duplication of code is done by using libraries like Phonon, Xine, GStreamer,… They implement individual volume control already, so there’s no need the application has to reimplement this.

  8. Doesn’t make the deal to get totally rid of it, try urpme libpulseaudio0 and see how amarok, ffmpeg, vlc, audacious, mplayer,etc.

  9. Sorry I didn’t mean to suggest that the app should not *expose* this kind of functionality. It should be able to expose it to the user for sure, for the reason you suggest. It’s just why implement a volume adjustment algorithm in every app that needs it…. just instruct the output system to change the volume of *the stream* not necessarily the overall system.

    That way you could leave system volume at, say 95-100% at all times and have all new streams come in at the normal, nice volume of say 60%. If I want to turn down the system volume I might use the buttons on my laptop or keyboard or the volume control applet. If I want to adjust the currently playing stream, I can just use the app’s volume adjustment system (which is just a wrapper to the pulse stream adjustment).

    Sure the library may provide a nice way to adjust the volume but that then still has to be exposed in the application, remembered and stored accordingly (assuming you wan the app to remember your previous settings). If you do it via pulse all you need to do is query the volume to see what it’s currently at and provide bindings for adjusting up/down and mute. IMO this is simpler logic but perhaps I’m missing something.

    I don’t really feel super strongly about this, it’s just that to me pulse seems most logical.

  10. I was reading about this pulseaudio thing. ITS JUST ANOTHER SOUND SERVER !! why not extend ALSA to do the same things. This is why people are scared of linux.. Some idiot developer always tries to reinvent the wheel instead of improving on it creating yet another mess and bugs that the user has to deal with. What is the reason behind this and not just fixing or adding onto ALSA ?

  11. You clearly haven’t taking the time to read up very much then if that’s your opinion. ALSA is not the be all and end all. Why should it be extended? It works very well at doing the low level driver interface, why should it have to take care of mixing, combining and other such userspace tasks? The fact that these are even part of ALSA in the first place is arguably the design mistake. Should we just bad designs and never fix them or should people actually come up with clean designs for the real problems and create good solution?

    To call it “Just another sound server” does it a huge disservice, not because it is another sound server but because it is building on the best designs laid down for handling sound in *all* operating systems, that includes OSX and Vista as well as other *nix’s.

    Sometimes the only way to clean up the mess is to implement it properly. If you’ve worked at all with Pulseaudio and seen it in action you would appreciate this. The fact that *all* major distros are pushing it and supporting it should make you realise that you’re perhaps not fully realising what is going on. I’d recommend you read Lennart’s very detailed slides over at foss.in if you want to get a good grounding on that PA is all about.

  12. I _had to_ uninstall pulseaudio because sound was cutting like hell – what ever I tried. (Yes, I was in the pulse-rt group – and yes, I enabled realtime scheduling).

    Apparently pulseaudio just does NOT work in older hardware (2.4G P4).

    And yes, pulseaudio stopping audio when moving to another vt… That’s just insanity!

  13. Well, on older h/w it’s generally recommended to turn down the resampling quality. Quality vs. CPU is a hard default to set. We opted for a fairly average one as a compromise. I’ve spoken to many people who happily give up the extra cycles for the quality but an equal number who feel the opposite :)

    As for the stopping of the music when switching to a VT thing, this is not actually pulseaudio that’s doing this. It’s Console Kit. It determines what session is currently “active” and gives that user the right to certain devices (the audio h/w being just one such device). Pulseaudio listens to this information and automatically shuts things down. You can disable this behaviour very easily in draksound, but the flipside is that visual/graphical userswitching will not work correctly and will break just like in the old days. One step forward and two steps back IMO. Personally I like it the new way :)

  14. PA may be the future, and the adoption rate by distros seems to indicate that it is, but at the moment it seems very poorly implemented.

    I have *no* complex sound requirements — all I want to do is watch videos online, play mp3s, play streaming music. Simple stuff. The problem is that the default PulseAudio implementation that ships with Ubuntu 8.04 can’t satisfy these simple requirements. As soon as *any* application plays a sound (whether that be firefox, amarok, or anything else), no other application can use the sound system. Also, this also prevent the system shutting down cleanly, since ALSA hangs — requiring a hard reboot.

    This is completely unacceptable, and needs to be fixed. I don’t know whether this is the fault of the PA devs, or the Ubuntu folks who chose the default settings, but *someone* needs to take responsibility to have this sorted out.

    Until then, perhaps PA shouldn’t be shipping with new distros.

  15. Steve please stop spreading FUD. One of the primary things Pulseaudio does is mixing (i.e. allowing multiple applications to use the sound hardware at the same time). You cannot configure this nor turn it off!

    So whatever you are doing on your system, you’re certainly *not* using Pulseaudio!

    Now I don’t know how Ubuntu has configured things, but we spend a long time getting things right in Mandriva. We had to patch quite a few apps to make them play nice but the end product was a satisfying one, both for the vast majority of our users and for most of the devs (tho’ as expected, there are always those who do not like it!).

    If you want help working out what the hell your system is doing, then pop along to #pulseaudio on freenode and someone will be able to explain things a little to you.

  16. The reason I blame PA, is that I found the following in my logs, and the timestamp agrees perfectly with the Amarok crash,

    ./syslog.0:Jul 3 17:54:54 home-desktop pulseaudio[13934]: module-alsa-sink.c: Error opening PCM device front:0: Device or resource busy

    I then did a bit of searching on this error, and found a *lot* of people complaining about PA. Eventually I found a link to the PA bug website for a bug related exactly to my problem. The PA maintainers had closed the bug since “PA behaves correctly: it puts a limit on the number of clients that may connect.”

    http://pulseaudio.org/ticket/313

    I understood this to mean that PA, by design, had locked my audio to the firefox stream, thus denying access to Amarok.

    This also matches well with reports that disabling PA unlocks the sound system, and then all audio events queued since the PA lock-up are then passed to the speakers.

    Please do not accuse me of spreading FUD. I have been a member of the Linux community of years, and have many thousand posts on various forums helping out other users. I was *not* spreading FUD — I was reporting my experience and my opinions, and, if you were to have a browse through the Ubuntu forums, you would find that these match the experience and opinions of many many other users.

  17. No you are totally misinterpreting that log entry. Please pop on IRC and myself and others can help you.

    Pulse will limit the number of connections (and I can’t remember what that upper limit is, but it’s is way bigger than you’ll practically need.

    This error is basically pulse saying it cannot open the front:0 device as it is in use by another application (e.g. something else has claimed exclusive access to the h/w). Pulse may indeed grab the audio hardware but alsa should be configured to route the “default” device via pulse and everything works as expected with all apps having access to audio “hardware”.

    Pulse is not able to “lock your audio to the firefox stream” but if Firefox is eating all the streams, then this is probably an issue with an old version of Flash plugin which used the ALSA API totally incorrectly (opening as many connections as possible!). This has been fixed in newer flash plugins but the pulseaudio community also worked around this bug (in a closed source app!) via the libflashsupport plugin API. So the community has done everything they can to ensure this isn’t a problem.

    So I can only assume that Ubuntu folks didn’t do enough QA into ensuring supporting packages were installed and/or alsa redirection was setup by default etc. Having not used it personally I cannot comment on this as I’m just going on your experience.

    It’s people having inital bad experiences and then assuming the fault/blame is at pulse’s door that really doesn’t help things. Just dropping in on #pulseaudio and asking a few questions would have told you the root cause of your problem almost immediately. I appreciate you didn’t mean to spread FUD but that’s basically what it boils down to (and everyone is guilty of that every now and then even if they don’t intend to!) Opinions are all well and good (we all have ’em!) but when they are based on incorrect assumptions etc, such comments just spread the misunderstanding and create a general negative feeling which is not deserved.

    Pop in on IRC and hopefully we can help you get a nice working setup going which you can then use to help other Ubuntu users :)

  18. Thanks for the dialogue Colin. I appreciate it.

    I go back and forward on this issue, but I think the answer to my question in my first post (i.e. are the Ubuntu or PA devs to blame for this) is that I think the Ubuntu folks are at fault.

    I say this cos I was able to find a guide to get things (almost) working,
    http://ph.ubuntuforums.com/showthread.php?s=55df5955610c29206ef190ac90f5159d&t=789578

    This got everything working the way I want — I can flip between youtube on firefox and amarok, and even play them simultaneously, with no problems. Even after doing all this, my system is able to reboot properly. The fact that I was able to (almost) get it running properly suggests that the Ubuntu devs could have arranged for this to be the default set up, which is why I blame them.

    The reason I say “almost” is that the problem hasn’t completely disappeared. After a while of playing streaming music on Amarok (maybe 30 minutes?), Amarok crashed and had to be killed. I was able to restart it, but it crashed hard again about 2 mins later. Again I tried to reboot, and it hung when trying to shut down alsa.

    *sigh*

    Anyway, I’ve just been on #pulseaudio and #ubuntu, and I got a bit of help, so maybe I won’t go the route of installing Suse that I was planning…. :D

Comments are closed.