Forgot your password?
typodupeerror
Linux

PulseAudio Creator Responds To Critics 815

Posted by kdawson
from the louder-please dept.
Dan Jones writes "As recently discussed here, Linux sound development has come under fire for being overly complex and, more specifically, PulseAudio has been criticized for not being a 'good idea.' In a lengthy interview, PulseAudio creator Lennart Poettering has responded to the many critics of the new-generation sound server and says such complaints and criticisms about PulseAudio in some Internet forums are not really shared by the vast majority of technical people. While Poettering admits PulseAudio itself is not bug-free, he believes the majority of issues are being triggered by misbehaving drivers or applications."
This discussion has been archived. No new comments can be posted.

PulseAudio Creator Responds To Critics

Comments Filter:
  • by Anonymous Coward on Monday October 19, 2009 @04:43AM (#29791259)

    Firrrrrsssst P Po Po sssst

    • Who knew? (Score:5, Funny)

      by PCM2 (4486) on Monday October 19, 2009 @05:17AM (#29791433) Homepage

      Lady Gaga apparently uses Linux.

    • by Anonymous Coward on Monday October 19, 2009 @05:44AM (#29791543)

      This is the only situation that anyone says: "If it has Pulse... its dead"

      • by Sillygates (967271) on Monday October 19, 2009 @11:37AM (#29794831) Homepage Journal
        Right before all the distributions started switching to PulseAudio, I remember thinking about how alsa was becoming stable (and "the" audio standard), and I wasn't seeing anyone with sound issues anymore.

        Granted, alsa alone isn't as versatile as pulseaudio, but there is value in sticking to a 'pretty good' solution, even if it might not be the best.

        An interesting side note on audio APIs: http://blogs.adobe.com/penguin.swf/linuxaudio.png [adobe.com]
        • by Tetsujin (103070) on Monday October 19, 2009 @12:18PM (#29795427) Homepage Journal

          An interesting side note on audio APIs: http://blogs.adobe.com/penguin.swf/linuxaudio.png [adobe.com]

          Man, not that bullshit again...

          Let's break this down.
          First you have platform independence layers - things like ClanLib, SDL, libao, PortAudio, Allegro, and Open AL. These would be present on any platform. That's the point of them. The diagram seems to go out of its way to mix these in with lower-level technologies, as if to make it less obvious that they're just included to pad out the diagram.

          Then there's the trio of obsolete network audio servers: NAS, ESD, and aRts... I suppose if I were to fire up a quick game of xpilot then I might want NAS, but otherwise one can usually assume these days that these three servers aren't installed and don't need to be.

          There's FFADO - which is relevant if you're using a firewire audio device... How many people do this? I guess it could be popular among musicians and sound techs - have audio hardware outside the computer's case, accessed via a bus that isn't USB... But this is a driver layer, not an API layer - and these days it seems FFADO provides an ALSA interface, so I think the complaint here is obsolete.

          That leaves three modern sound servers (Jack, Pulse, and GStreamer) and two low-level APIs (Alsa and OSS). This is still a bit of an unfortunate mess IMO but nowhere near the rat's nest implied by the diagram.

    • by Runaway1956 (1322357) * on Monday October 19, 2009 @06:51AM (#29791867) Homepage Journal

      You should be using OSS4. I put up with the Pulse idiosyncracies until my virtual machines spazzed out. Started researching my options, and found that Open Sound was moving past the deprecated OSS3, which wasn't much better than Pulse.

      Since I've compiled and installed Open Sound, I have no more sound problems, period. Everything works the way it's supposed to.

      If Pulse and Alsa get their shit together, fine. If not, I'm a devoted OSS fan. Before anyone runs off to experiment, be warned - you will probably have to spend a few minutes purging Alsa from your system. There is no co-existence of the two, at least not on Ubuntu. If you're not a Linux guru, plan on following a how-to, and plan on spending a couple hours getting it right.

      http://www.opensound.com/ [opensound.com]
      https://help.ubuntu.com/community/OpenSound [ubuntu.com]

      • by icebraining (1313345) on Monday October 19, 2009 @07:05AM (#29791955) Homepage

        I'm an OSSv4 converted too - being being unable to get vmix or Pulse to work right, Alsa could turn the volume as high as Windows. Now in OSSv4 everything works fine, except being unable to detect the jack, which is annoying.

      • by apoc.famine (621563) <`apoc.famine' `at' `gmail.com'> on Monday October 19, 2009 @10:54AM (#29794283) Homepage Journal

        I'm really curious - I haven't tried OSS4 yet, but the one thing I haven't ever gotten working on linux is the following setup:
         
        Analog/Digital speakers, with a USB headset.
         
        Can OSS4 handle USB sound? Can it mix multiple streams? Does it have an easy way to switch between input/output devices?
         
        Pulse gave me hope for the above. Then fell flat on its face. I've never been able to get dmix to handle this setup, and ALSA doesn't seem to do it.
         
        I hate to say it as a linux fanboy, but I want audio like Windows. Right-click on my audio button, and in two clicks I can choose my input and output devices, and all sounds are seamlessly mixed to make that happen. I don't really care about network audio, or any of the other fancy-ass shit that pulseaudio is supposed to do.
         
        Really, I use a desktop, and I have multiple audio sources and devices. Mix them automatically, and give me a quick gui control for which piece of hardware should be handling each. That's all I really want.

  • who's to blame. (Score:5, Insightful)

    by delirium of disorder (701392) on Monday October 19, 2009 @04:43AM (#29791261) Homepage Journal

    When an application can make the soundsystem stop working for all other applications, than there is a bug in the soundsystem, not just the application that caused the problem.

    • Re:who's to blame. (Score:5, Insightful)

      by Jason Pollock (45537) on Monday October 19, 2009 @05:30AM (#29791481) Homepage

      Precisely. PulseAudio cost me a week of effort in building my media playing machine. An entire week of trying to figure out why XBMC and Boxee wouldn't talk to the sound card.

      As soon as I got rid of PulseAudio? It started working.

      When an API is supposedly compatible with something it is replacing, it is the _API's_ fault when an application stops working, not the application. We already had this argument with EXT4.

      PulseAudio - not ready for prime time.

      • Re:who's to blame. (Score:5, Informative)

        by John Betonschaar (178617) on Monday October 19, 2009 @07:17AM (#29792011)

        Same here, yesterday I spent 4 hours on a media PC I built and configured for my brother in law, up to the point that everything worked at my place using SPDIF output (which already cost me 2 hours to get working in the first place). I arrive at his place, turns out he wants to use the HDMI output instead of the SPDIF. No problem, you'd guess, just go to the sound preferences and select HDMI, right? Not on linux you don;t and not with PulseAudio apparently. After dicking around with the 4 different mixers (gnome, alsmixer, pulseaudio) and 4 layers of configuration (gnome sound settings, pulseaudio settings, alsa settings, gstreamer settings) it turned out that I had to put a file called .asoundrc with some cryptic content in my home directory, and in some tab called 'switches' in the PulseAudio advanced settings had to check 4 boxes that did something with an 'iec958' (whatever that may be) and then, finally, it worked. Not very well by the way because the Ubuntu startup sound pops and stutters like hell, but after that it's more or less 'ok'.

        I've been using Linux for over 10 years now and I've been telling people over and over again how even your grandma could use it, but sadly, I have to conclude that in some ways it still sucks balls for people who don't like fiddling around with obscure settings, configuration files, 4 layers of sound settings etc. I really love linux myself but let's face it, for example sound and wireless (damn wpasupplicant and 'wlan0: link not ready) are still lightyears behind Windows and (even more so) OS X in terms of usability.

    • Re:who's to blame. (Score:4, Insightful)

      by phantomcircuit (938963) on Monday October 19, 2009 @06:20AM (#29791689) Homepage

      I believe that he was saying PulseAudio was calling low level ALSA apis that are not often used and as such many drivers have never actually been widely tested. So PulseAudio is causing the drivers to crash.

      I do not believe he was saying that an application connected to PulseAudio should not be able to crash PulseAudio.

  • Useless (Score:5, Insightful)

    by Carewolf (581105) on Monday October 19, 2009 @04:44AM (#29791269) Homepage

    The idea is great. PulseAudio is an excellent solution for networked audio and thin unix clients. Now the problem is the people and the distros installing it by default on a desktop where it is utterly useless. No matter how close to bug-free it is, it is an unneeded source of bugs in that case.

    • Re:Useless (Score:5, Informative)

      by Cyberax (705495) on Monday October 19, 2009 @04:49AM (#29791287)

      PulseAudio is NOT unneeded.

      First, Bluetooth audio _sucks_ without PulseAudio.

      Second, you NEED to have a sound daemon to properly manage the sound system and other sound daemons suck.

      Third, ALSA's volume controls are horrible and PulseAudio really helps here.

      Fourth, PulseAudio has a ton of other nice features: streams tagging and automatic volume control, joined devices, mic boost, etc.

      • Re:Useless (Score:5, Insightful)

        by Anonymous Coward on Monday October 19, 2009 @04:56AM (#29791319)

        ...Fourth, PulseAudio has a ton of other nice features...

        Now if only it would actually play music without skipping, freezing, or using 30+ percent of the CPU. Sheesh!

        • Re:Useless (Score:5, Insightful)

          by Per Wigren (5315) on Monday October 19, 2009 @05:14AM (#29791411) Homepage

          Now if only it would actually play music without skipping, freezing, or using 30+ percent of the CPU. Sheesh!

          It will, if both your kernel and Pulseaudio are properly configured for low-latency desktop usage (realtime privileges, 1000hz timer, etc). While I fully understand you being annoyed that your current distro/version ships with a default configuration that isn't fully adjusted to this very common usage pattern, it also means that the situation will get better as distributions learn how to properly integrate Pulseaudio and the remaining bugs in Pulseaudio itself are fixed and it gets better at automatically detecting and adjusting to different hardware setups. This includes making the ALSA drivers better at reporting which jacks are plugged in and things like that.

          • Re:Useless (Score:5, Insightful)

            by segedunum (883035) on Monday October 19, 2009 @09:56AM (#29793443)

            It will, if both your kernel and Pulseaudio are properly configured for low-latency desktop usage (realtime privileges, 1000hz timer, etc).

            This is bullshit. No one should ever need to configure a sound system to get it to work on a basic set up and I'm sure that blaming distros or blaming kernels looks like the easy way out. No one needed to configure OSS, no one needed to configure ALSA and no one has needed to configure arts to get sound out of their speakers reliably on first start up. I've seen the mail where Lennart is blaming various Linux kernels for several hundred millisecond latencies and that is simply insane. Either he's lying or you've got a piece of software that is ridiculously sensitive and ultimately broken.

            This includes making the ALSA drivers better at reporting which jacks are plugged in and things like that.

            Then fix ALSA or use OSS before you start retrofitting bullshit sound servers that breaks a lot of things. We've had an unhappy history with sound servers in the Linux world and no one seems to have learned the lesson.

          • by sean.peters (568334) on Monday October 19, 2009 @12:35PM (#29795705) Homepage

            While I fully understand you being annoyed that your current distro/version ships with a default configuration that isn't fully adjusted to this very common usage pattern, it also means that the situation will get better as distributions learn how to properly integrate Pulseaudio and the remaining bugs in Pulseaudio itself are fixed and it gets better at automatically detecting and adjusting to different hardware setups.

            Look, I understand that getting this stuff right is a hard problem and takes some effort to get resolved, and that' s not necessarily the fault of the developer. But it's not my fault either. I don't have time for this kind of thing - while there was a day when I really enjoyed spending a bunch of time fiddling around with my computer to get it to work right, those days are mostly over for me now. I need sound to "just work", and if Pulseaudio doesn't, then I'm not using it.

      • Re:Useless (Score:4, Insightful)

        by J Story (30227) on Monday October 19, 2009 @05:03AM (#29791359) Homepage

        PulseAudio is demonspawn.

        OSS -- *not* the old stuff that comes with most distributions, but the Open Source OSS v4 at opensound.com -- is a better alternative to ALSA and the PulseAudio abomination.

        • Re: (Score:3, Interesting)

          by Anonymous Coward

          From the wiki http://www.opensound.com/wiki/index.php/Main_Page [opensound.com]:

          Supported audio formats
          - Supports 8/16/24/32 bits/sample audio formats
          - Supports sampling rates from 8KHz up to 200KHz
          - Supports mono, stereo, quad, 5.1, 7.1 and multichannel audio devices
          - Transparent Software based Audio Mixer
          - Allows applications to share the same "real" audio device regardless of what format is requested by the application.
          - Supports recording and full duplex in addition to playback.
          - Ability to mix stereo and multichannel

      • Re:Useless (Score:5, Insightful)

        by jedidiah (1196) on Monday October 19, 2009 @09:08AM (#29792845) Homepage

        > First, Bluetooth audio _sucks_ without PulseAudio. ...which means that all of us without "bluetooth audio" couldn't care less.

        > Second, you NEED to have a sound daemon to properly manage the sound system and other sound daemons suck.

        No you don't. No they don't.

        For the mundane user, ALSA was doing fine before Pulse came along. For most of us,
        PulseAudio was a solution in search of a problem and just something else with more
        moving parts to break. Even now, most users would be best served by just un-installing
        PulseAudio entirely.

    • Re: (Score:3, Funny)

      by Anonymous Coward

      Networked audio and thin unix clients ... just what I need at home! I do hope that my netbook can stream PulseAudio to my PDA!

    • Re:Useless (Score:4, Insightful)

      by Ant P. (974313) on Monday October 19, 2009 @05:02AM (#29791349) Homepage

      The problem is the fact PulseAudio is designed to be used only in that utterly useless way.

      Want to run mpd? Too bad, PulseAudio doesn't run as a system daemon. Want a headless server? Too bad, you have to have GNOME running on it and be logged in for this to work properly.
      Want your damn sound card to just work already? 99% of the answers will be "uninstall PulseAudio". A better answer is to not use a distro that dumps it on you in the first place.

      • Re:Useless (Score:4, Informative)

        by setagllib (753300) on Monday October 19, 2009 @05:21AM (#29791451)

        Ok, what? It definitely works as a daemon. But even if it didn't, what's the issue? If you have a dedicated headless MPD server, you gain nothing by using Pulse. If you have plenty of desktop applications that all want sound input/output, Pulse solves basically everything.

        • Re:Useless (Score:5, Informative)

          by mickwd (196449) on Monday October 19, 2009 @05:57AM (#29791595)

          It definitely works as a daemon

          On Gentoo:

          desktop ~ # /etc/init.d/pulseaudio start
          * Please don't use system wide PulseAudio unless you read the
          * documentation available at http://www.pulseaudio.org/wiki/WhatIsWrongWithSystemMode [pulseaudio.org]
          *
          * When you're done, please set the variable PULSEAUDIO_SHOULD_NOT_GO_SYSTEMWIDE in
          * /etc/conf.d/pulseaudio . Please remember that upstream does not support this mode
          * when used for standard desktop configurations.
          * ERROR: pulseaudio failed to start

          Quoted from that link: "The maintainer's interest in making sure system mode is well supported is rather minimal."

    • by jonaskoelker (922170) <jonaskoelker@ g n u .org> on Monday October 19, 2009 @05:06AM (#29791365) Homepage

      Now the problem is the people and the distros installing it by default on a desktop where it is utterly useless.

      In fact it's worse than useless (on Ubuntu): whenever I move away from my wireless access point at home (i.e. I'm on my bike on my way to the university), my sound stutters; this is probably PulseAudio spending too much time on making a new map of the network and too little time on actually handling sound waves (but I'm speculating).

      Did no one test this? Am I the only person using a "ThinkPod" as a portable music player? Oh, I guess it's not one of those 95% most common use cases, so it's no biggie if it isn't handled properly.

      Except that there are twenty disjoint chunks of 5% least common use cases not being fixed because they don't affect that many people, except everyone is affected by one... grr... </hyperbole> <apology/>

    • Re: (Score:3, Informative)

      by shadowknot (853491) *

      The idea is great. PulseAudio is an excellent solution for networked audio and thin unix clients. Now the problem is the people and the distros installing it by default on a desktop where it is utterly useless. No matter how close to bug-free it is, it is an unneeded source of bugs in that case.

      But not for dual-boot workstations where users' home dirs are samba shares as it leaves symlinks to /tmp in the .pulse directory of each user that, when a user logs on to a different workstation, prevent Gnome from loading unless the pulse processes are killed. We have had to dump pulse in favor of esound (I work at a University) which doesn't have these issues. Sound, thankfully, isn't that critical on our dual boot XP/Ubuntu boxes but pulse has caused us all manner of issues with these pesky symlinks.

  • by ZorbaTHut (126196) on Monday October 19, 2009 @04:46AM (#29791275) Homepage

    If we make PA expect more correct behaviour from the apps, or that applications stop making particular assumptions about the audio stack, we need to fix the applications at the same time.

    This is not entirely true.

    Now, I don't know what the exact bugs are that are causing problems. But the API should be stable no matter what happens to the outside. There should be no way to destabilize or crash the audio layer from a usermode application. So, if by "expect more correct behavior from the apps" he means "garbage in, garbage out", then that's fine. But if by "expect more correct behavior from the apps" he means "no error checking and if any app screws up then everything melts", then that's not fine.

    I don't know which he means, but I've seen instances of both.

    • by abigsmurf (919188) on Monday October 19, 2009 @06:19AM (#29791683)
      It's actually extremely difficult to do a reliable sound system. The drivers for a large number of cards are pretty bad.

      From what I understand up until recently most OS' treated sound cards like any other hardware. If you got a bad response from them, the OS would halt the system rather than risk physical damage. Hence sound cards are one of the leading causes of blue screens in windows 9x and XP.

      One of the things Vista did right was recognise that drivers for sound cards can't be trusted and put in an additional software layer between the hardware and drivers to minimise sound card related blue screens. It's why Directsound has been removed from DX and one of the biggest reasons DX10 can't run on XP.
      • by Sycraft-fu (314770) on Monday October 19, 2009 @08:03AM (#29792295)

        A correction here is that DirectSound has not been removed, it is still a major API. What has been removed is hardware acceleration of DirectSound. In Vista/7 all DirectSound audio is software processed. The soundcard can't accelerate any of it.

        The real problem was actually that there were few hardware sound accelerators on the market. Most cards were (and are today) little more than buffers you could write data in to to be played. Ok, fair enough. However what happened was that the people who made these cards wanted to support all the nifty hardware features since games made use of them. So they'd write these big complex drivers that played make believe and pretended to do hardware acceleration, all in the kernel of course. That is where the problems happened.

        So in NT 6 (Vista and 7) that was removed. All audio is handled in software, and the interface to hardware is just one of giving out the finished sound to be played. Much less room for problems, though more computationally intensive. Not a problem though since processors are much faster.

        Hardware acceleration now can only be done using other APIs. That is how Creative Labs does it. They implement OpenAL (their own API) on their cards in parallel to the Windows APIs. It talks straight to the card, bypassing Windows's processing.

        That's not the only big usermode DirectX related change though, the graphics subsystem was moved in to user mode too. Though this still does hardware acceleration, of course, the drivers were all moved up to user space. One side effect of this that you notice is that when you install new drivers, you don't need to reboot.

  • by amorsen (7485) <benny+slashdot@amorsen.dk> on Monday October 19, 2009 @04:48AM (#29791279)

    The problem is that the implementation sucks, and that bugs are being ignored.

    I'll perhaps reconsider my stance when pulseaudio starts using less CPU than the JVM when playing Puzzle Pirates. Finally something more bloated than Java, I guess.

    • by QuoteMstr (55051) <dan.colascione@gmail.com> on Monday October 19, 2009 @07:30AM (#29792081)

      The problem is that the implementation sucks, and that bugs are being ignored.

      No, the problem is that the implementation sucked. Past tense. There were various CPU-eating problems. They were fixed a long time ago.

      Really, the entire Linux sound system sucks. PulseAudio is one of the better parts of it. But because PulseAudio is visible, and because an old distribution once shipped with a CPU-eating PulseAudio, it makes the perfect scapegoat today.

  • by jonaskoelker (922170) <jonaskoelker@ g n u .org> on Monday October 19, 2009 @04:53AM (#29791305) Homepage

    While Poettering admits PulseAudio itself is not bug-free, he believes the majority of issues are being triggered by misbehaving drivers or applications.

    Well, the way I see it, I can either use alsa and have (as far as I can tell) no bugs, or I can use PulseAudio and have more features and more bugs.

    That might not be PulseAudio's fault, but it still means that if I use PulseAudio I will have a buggy sound system. Why do I want that? Why do I want it even if it's only buggy until all the applications get fixed?

    Also, the promise of networked sound is kinda... meh... maybe I'd be happy if all my laptop sound got moved to my desktop box (which is connected to my stereo) automatically whenever my laptop is connected to my home access point (and, conversely, my desktop's sound automatically gets routed to my laptop whenever my laptop does an ssh home and is not around my home access point). But as far as I can tell, this is a bitch to set up, and I'm really not inclined to go clicking around some unintuitive menu system to set my sound up right every time I leave home or go back.

    So what's the benefit of PulseAudio again?

  • by Valdrax (32670) on Monday October 19, 2009 @04:59AM (#29791335)

    I've read the background articles (but not the featured rebuttal about PulseAudio yet), and I was wondering why OSS was "deprecated" in favor of ALSA and whether (and if not why not) there's a possibility of OSSv4 being put back into the kernel. Anyone know?

    • by Ant P. (974313) on Monday October 19, 2009 @05:14AM (#29791407) Homepage

      OSS was deprecated because 4front pulled the rug out from under users and started demanding money for binary-only versions, and it was easier to write an entire API from scratch instead of trying to fix the crap they'd left in the kernel.

      OSS4 is never going in because 4front has a dangerously wrong idea of how the GPL2 works [4front-tech.com] and think they they have the right to infect applications using this API with their licence.

      Do not want!

      • by LizardKing (5245) on Monday October 19, 2009 @05:32AM (#29791495)

        The 4Front interpretation of GPLv2 is irrelevant - the source code is triple-licensed under GPLv2, CDDL and BSD licenses. ALSA is an excellent example of Linux throwing away a solid API and implementation that could have evolved to support the few critical features it lacked (which is exactly what happened in FreeBSD for example) in favour of a half-baked alternative. The original ALSA API is poorly designed by people who clearly have very limited knowledge of OO principles, but wanted to apply them all the same. This piss poor API was never well documented, and the actual audio drivers are not of the same quality as the ones in OSSv4. The ALSA developers answer to the poor API? Slap another, equally poor, equally undocumented API on top of it. What a fucking mess.

      • Re: (Score:3, Informative)

        by blind biker (1066130)

        Meanwhile FreeBSD doesn't give a crap about what zealots want or do not want, and does just fine with sound.

  • by Max Romantschuk (132276) <max@romantschuk.fi> on Monday October 19, 2009 @05:09AM (#29791393) Homepage

    The largest problem with Linux audio is not really any particular driver model / sound server. OSS, ALSA, PulseAudio and Jack all work when set up properly, with supporting hardware, and supporting software. But it's never a given that a particular app will support whatever you're using, or give you the choice to select your output device if you have multiple sound cards.

    I've been running Ubuntu for a long time now, and recently installed Windows as a dual boot for making music. Why? I can spend X hours on setting stuff up, or I can spend X hours on making music. I can simply count on any app that matters supporting ASIO or DirectSound on Windows.

    While I actively try to convert people to Ubuntu for regular desktop apps I still tell people who plan to do audio/video stuff to go for Windows/OS X. While it's totally doable to set up a working environment in Linux if you know what you want and which apps you want, I like to play with stuff for fun. I'd rather invest my time in having fun creating content than trying to get stuff to work.

    (And yes, I've tried Ubuntu Studio. Nice, but not there yet for me.)

    • by Anonymous Coward on Monday October 19, 2009 @06:16AM (#29791671)

      A common problem, not helped by the tendency of people to reinvent the wheel (and the interfaces). Very much a linux problem, though.

      Point in case? ifconfig. There's been what, two supposedly better interfaces both completely incompatible with everyone else's (read: other unices). And then you need a separate command for the low-level stuff (ethtool), or even a suite of commands to do the same (iwconfig/iwlist/...) with vague documentation and prominently featuring things already moved to a different command with no mention this is the case.

      Ah, documentation. On linux, most entries in the online reference manual (`man pages') send you off to *censored* info requiring a *censored* "info viewer" that expects you to know emacs and two to one will give you the manpage again only this time you need *censored* emacs contortions to get out of dodge. Couldn't it just bail out and tell me there was no info? Nevermind, I knew that already. I'll move on to a different system. In my case, still a unix, but no linux, kthx.

      Should I mention the three, no four, wifi stacks in linux? Why isn't there just one that does it all? What about bluetooth? USB cameras? Video? Similarly: The VM. The Scheduler. I'm sure there are many more examples right round the corner, for reinventing wheels for the sake of reinventing wheels is the linux way. Reinventing wheels squarely for that special corporate sauce enhanced taste is someone else's game, but rightly there isn't much difference for the end user.

      Compare with FreeBSD's ifconfig: It does all that, isn't hopelessly buggy, supports modern notations, and can be extended further should the need arise. And it still is compatible with everyone else's ifconfig and no nagging it has something else that's supposedly better only nobody tells you why, or how. Also: Only one wifi stack. One sound system. Ok, so there's three packet filtering interfaces, but at least you can use them concurrently if you wish, and all of them work with all the supported hardware. My point? There are non-windows systems Out There that are well integrated, but none of them are called linux, or gnu.

      As to network audio, I'm not sure I want it on that level, there. Unix has always been easily extensible even if through the virtue of a small shell script and a few judicious triggers. So I come home and drop my laptop in the network, what's to stop me from having dhclient trigger a script that sets up simple streaming to my stereo? Heck, I could stream over FTP if I wanted to. Why do I need pulse audio and its horde of bugs for that?

  • Distribution problem (Score:5, Informative)

    by LS (57954) on Monday October 19, 2009 @05:22AM (#29791455) Homepage

    I've read in several places that the main problem with PulseAudio is not its design and implementation, but its instantiation. Many distributions apparently do not properly set up PulseAudio, causing it to behave unexpectedly. I found this to be the case with Ubuntu 9.04. PulseAudio worked like crap until I followed the following directions to get it set up. It's been working like a dream ever since:

    http://ubuntuforums.org/showthread.php?t=789578 [ubuntuforums.org]

    LS

  • by WWWWolf (2428) <wwwwolf@iki.fi> on Monday October 19, 2009 @05:34AM (#29791509) Homepage

    I disagree with the original article [blogspot.com]: ALSA is the way to go, I have drivers for all cards I've thrown at it, all applications imaginable that support ALSA work just fine for me, and no, as a OSS-to-ALSA changeover survivor, I don't want to change everything to another frigging API yet again (much less back to OSS), thank you very much. And while PulseAudio is less than perfect right now, I recognise it has uses.

    But that's just that - it has uses. In its current state, I'm not using it for plain-ordinary music playing on my Debian system. I don't think it's ready enough as a common day-to-day audio routing thing. Still too many problems.

    An example case: I was really disappointed when I upgraded Ubuntu on an older computer (600Mhz Pentium III with 256M memory and ESS Solo 1 onboard audio, plenty good enough for OpenOffice.org and web browsing, even ran Compiz at very good performance on GeForce 2 MX =) and sound playback started to just plain suck, when it previously worked just fine with straight-up app-to-ALSA playback. The machine just wasn't fast enough to route stuff through an application, plain and simple. And now Ubuntu foisted PulseAudio in. Uninstall PulseAudio = uninstall entire frigging GNOME desktop. I kept trying to tell it "no, I just want ALSA playback" in sound settings. No dice, pulseaudio kept respawning and hogging audio device all to itself. I kept disabling shit from all places imaginable. No dice, pulseaudio kept respawning. Now, I'm going insane (an unrelated story). I'll be armed with GCC and some dummy binaries. Mheheh. Muahaha. MUAHAHAHAHA. ...any better ideas?

  • by Idaho (12907) on Monday October 19, 2009 @05:38AM (#29791519)

    While Poettering admits PulseAudio itself is not bug-free, he believes the majority of issues are being triggered by misbehaving drivers or applications.

    Even if he may be 100% right about that: way not to get the point!

    I don't care whether problems are caused by the kernel, a driver, an application, the phase of the moon, or whatever. The thing is, if some "trivial" piece of hardware which has been part of mostly every computer since about 1990, still *does not fucking work* correctly today, I don't give a rat's ass whose fault that is. Especially if it appears the same "problems" have been solved satisfactorily at least 10 years ago on every other OS in mainstream use.

    In the meantime, Linux has changed both the audio driver model (ALSA, OSS, who knows what else), and in addition to that, the "application interfaces" (arts, esd, PulseAudio, etc.) so frequently, that it is hardly any wonder that application developers are taking the piss and not updating their software to match the bugs/workarounds to whatever the current "flavor of the week" API for audio interfacing is.

    Perhaps PulseAudio is just getting most of the "blame" because it is the most recently changed part of the audio subsystem, so if things used to work before, and now they don't, of course you're going to blame PulseAudio. Even if it is not by itself the "real" culprit.

    • by r00t (33219) on Monday October 19, 2009 @06:26AM (#29791731) Journal

      That was on 486 hardware and even worse!

      The problems started with ESD or esound, the Enlightenment Sound Daemon. Prior to that, sound daemons were unusual. Nobody actually ran one. Enlightenment (the insane game-inspired window manager) got one, GNOME briefly used Enlightenment, and we've been stuck with sound daemons ever since.

      The OSS to ALSA transition was the other botch. It used to be that an app just did open() on /dev/audio or /dev/dsp and made sound. Any competant UNIX programmer could handle that. Now we have a kernel API that is essentially unusable, so you have to use ALSA libraries to do anything. Actually, those are **barely** usable.

      Really, it wasn't always like this. My 486 DX4-75 with 8 MB RAM (slackware, fvwm-1.x) could handle audio. Back then, programmers didn't fuck around adding bugs and bloat. They wrote stuff that worked, nice and solid, on the hardware that we had.

      • by Sycraft-fu (314770) on Monday October 19, 2009 @06:46AM (#29791833)

        One problem that many forget looking back on the "good old days" of sound is that you couldn't get sound from more than one thing. On single task OSes like DOS this wasn't a problem, you only ran one app. However for multi-tasking OSes it meant that whatever opened the soundcard first had control until it gave it up. This was problematic for many reasons. Meant that you couldn't even do something simple like play an alert sound from the OS if someone was playing MP3s (not such a problem in the 486 days since those were hard pressed to decode MP3s in realtime).

        Well, that's where sound daemons come in. The OS mixes sounds from multiple apps and sends it to the soundcard. Thus you can have multiple programs using sound, just like video. What's more, it'll let you do things like control the volume if an app neglects a volume control. Firefox doesn't seem to have a volume control, but the Windows 7 mixer has no problem adjusting its volume, independent of the system.

        There is no reason why this should be a problem. Windows and OS-X do it just fine. There is a sound layer the OS has that you write drivers for an all apps can interface with. You can extend/bypass that with your own APIs if needed (like OpenAL or ASIO). It works really well. For that matter on Windows now they have created the concept of Universal Audio Architecture which is a standard way for devices to expose their functions to Windows, and thus work without device specific drivers.

        There is no reason Linux can't do this as well. You can have an audio daemon, and should. What need to happen is time send to be spent designing things in an intelligent way first, and then implement them so that they don't change all the time. Have a standard ABI that the driver writers develop for, and a standard API(s) that the software developers write for. Have standard mechanisms for people to add to or override that if needed.

        It'll work fine, if designed well, implemented well, and not fucked with. You can't change the spec every other week. It needs to be laid out and stuck with.

        This isn't theoretical, as I said OS-X and Windows do it, and have been doing it for some time.

        • by TeknoHog (164938) on Monday October 19, 2009 @08:23AM (#29792431) Homepage Journal

          ALSA handles multiple sources well enough by itself, with the dmixer plugin.

          I imagine sound servers may have some legitimate uses, but for the software mixing, I don't see any reason why most users would need anything beyond plain ALSA. Thus it seems like a bad idea to run a sound server by default.

          I also use plain ALSA for making music, and when I play around with multiple sound cards, I want to set things up as directly as possible. The dmixer plugin is easy to bypass.

      • Re: (Score:3, Insightful)

        by Wonko the Sane (25252) *

        PulseAudio isn't written for the hardware of 10 years ago. It is written for 2009 where a typical user has multiple independent pieces of hardware each capable of sound input and/or output that may or may not be present all the time (webcams, headsets, bluetooth, etc.)

  • The Vista Defense! (Score:5, Insightful)

    by Beelzebud (1361137) on Monday October 19, 2009 @05:50AM (#29791573)
    I never thought I'd see a Linux advocate use the Vista Defense! It's the drivers, it's the software, it's something, but it's not my code!

    At least with Vista the problems with video drivers, and various other hardware devices was sorted out within a couple of months. In Linux the way audio is handled is an absolute mess.
  • by colin_s_guthrie (929758) on Monday October 19, 2009 @06:05AM (#29791627) Homepage

    I knew as soon as I read the headline here that this article would be jumped on by numerous "alsa is fine on it's own", "Why not OSS" and "PulseAudio is buggy blah blah" type posts but I didn't think that even the general slashdot hordes were that ignorant about what the hell PA is all about. I was sorely mistaken.

    PulseAudio is very little to do about "networked audio" which everyone and their dog seems to use as an example to reason "I do not need networked audio, therefore I do not need pulseaudio". It's just ignorance in the extreme.

    PulseAudio as an architecture is fast becoming the defacto standard on Linux, companies such as Intel, Nokia and Palm are putting significant resources into PA just now.

    OSSv4 or older flavours simply does not have the API to deal with a modern linux desktop, plain and simple. We can maybe get some of the more userspace stuff such as bluetooth or airtunes support (the support for which I added to PA myself) using some kind of CUSE support but that's only just landed in the kernel just now, and it really wouldn't be a proper solution (and guess what? it would need a daemon running anyway!!)

    As a PA developer and supporter, I've written up various articles explaining what PA is all about before and posted similar comments to mailing lists etc.
    You can read some of them here:
    http://colin.guthr.ie/2009/08/sound-on-linux-anti-fud-calm-certainty-and-confidence/ [guthr.ie]
    and
    http://thread.gmane.org/gmane.comp.kde.amarok.devel/15356 [gmane.org]

    I'll outline some of these things here to save you killing my poor server!

    More and more audio device *are* network based. Apple Airport Express devices are pretty popular these days. I have two bluetooth headsets and my hifi system also support bluetooth connections and my Playstation 3 supports uPNP. So lots of things relating to network Audio are popping up (which is nothing to do with pulse->pulse network connections which is arguably a toy, even if I do personally use it a lot!). I don't think these should be ignored. PulseAudio supports all of these devices right now (although I've not had time to try the uPNP stuff on my PS3 specifically so don't quote me on that!)

    In addition, rights access and management is a big issue. Today any modern linux desktop uses console kit to keep track of user sessions. When you switch from one user to another, console-kit ensures that the currently "active" user session is set to inactive, and it triggers udev callouts to remove the currently active users ACL on the /dev/snd/* nodes. (I seriously hope no one adds their user to the "audio" group these days!). This allows a new user to log in and get access to the sound hardware because they are now the "active" user. Switching between the two sessions triggers these ACL rewrites. Something has to manage this in applications so that they don't just bail out with EPERM errors. The sound has to go to /dev/null automatically without the application being aware of what is going on. Perhaps it can cork/uncork applications that listen for such signals so that music is paused etc. This is something that cannot be done without some kind of userspace daemon handling things.

    Then on to power consumption. What most people quite often fail to realise is that Latency is Good. If you can pump 20 seconds worth of audio into a buffer and then switch off until you're woken up 19.5 seconds later then this is great for power consumption. You need to disable hardware interrupts and use kernel level timing constructs to deal with this, and automatically reduce your wakeup time on the event of an underrun to reduce the likelihood of a future underrun occurring. You also have to have accurate timing information reported such that a/v applications can handle things like lipsyncing etc. (and remember that hoping for a low latency audio output is

    • by ardor (673957) on Monday October 19, 2009 @06:55AM (#29791897)

      Latency is Good

      No its not. Video playback with an audio lag of several seconds? Not good. Playing games with an audio lag of several seconds? Not good.

      As for the networked audio stuff, you mention UPnP. All you need for UPnP to work is a dedicated UPnP server like Mediatomb to stream your audio to the client. You do NOT need an audio daemon for this.

      • by QuoteMstr (55051) <dan.colascione@gmail.com> on Monday October 19, 2009 @07:42AM (#29792159)

        No its not. Video playback with an audio lag of several seconds? Not good.

        You're confusing synchronization and latency. There's no particular reason you can't buffer up a few seconds of audio, yet make sure that audio is played exactly when the video calls for it.

        • by _merlin (160982) on Monday October 19, 2009 @08:23AM (#29792445) Homepage Journal

          There's no particular reason you can't buffer up a few seconds of audio, yet make sure that audio is played exactly when the video calls for it.

          Yes there is: you don't want to be playing a game, and only seeing responses to your inputs seconds after you do things. Any noticeable input lag in a game ruins the experience. Ideally, you want no more than one frame of latency between reading inputs, running an iteration of your engine and getting it out to the display/speakers/haptics. Not all content is pre-recorded.

          • by QuoteMstr (55051) <dan.colascione@gmail.com> on Monday October 19, 2009 @08:27AM (#29792483)

            One of the nice things about PulseAudio's design [archive.org] is that it allows you to combine large buffers for some tasks with very low latency for others.

            PA configures the audio hardware to the largest playback buffer size possible, up to 2s. The sound card interrupts are disabled as far as possible (most of the time this means to simply lower NFRAGS to the minimal value supported by the hardware. It would be great if ALSA would allow us to disable sound card interrupts entirely). Then, PA constantly determines what the minimal latency requirement of all connected clients is. If no client specified any requirements we fill up the whole buffer all the time, i.e. have an actual latency of 2s. However, if some applications specified requirements, we take the lowest one and only use as much of the configured hardware buffer as this value allows us. In practice, this means we only partially fill the buffer each time we wake up. Then, we configure a system timer to wake us up 10ms before the buffer would run empty and fill it up again then. If the overall latency is configured to less than 10ms we wakeup after half the latency requested...

    • by Entrope (68843) on Monday October 19, 2009 @07:07AM (#29791983) Homepage

      A lot of devices stream data over a network and play it locally as audio. That does not necessarily make any of them a "network based" audio device in the sense that they can be driven by PA.

      Audio is not unique in needing device ACLs adjusted; it should not need a unique solution for doing that. In fact, having an audio server handle ACL adjustments when something else does that is a violation of the Unix philosophy of chaining together simple tools that focus on one thing.

      Application-controlled latency is good. Library-enforced latency is bad. Sending audio from one user-space process to another is a case of the latter.

      After reading your post made "as a PA developer", I'm even more down on it than before.

  • by Per Wigren (5315) on Monday October 19, 2009 @06:14AM (#29791663) Homepage
    A lot of the problems with Pulseaudio are caused by the misconfiguration of Ubuntu's default kernel. It seems that they will be making the upcoming Karmic Koala even worse, according to a small rant on Lennart's blog [0pointer.de] today.
    • Re: (Score:3, Interesting)

      by Entrope (68843)

      Lennart gripes in that post about some kernel patches that Ubuntu included -- but his fundamental complaint is that Ubuntu didn't add a different patch, to allow an application called rtkit to put other processes in real-time priority classes. (Running in a real-time class can improve latencies because that app gets to run ahead of most other apps and kernel tasks. A lot of the real-time development on Linux has been driven by audio people looking for more controlled latencies, but that was also before PA

      • by Per Wigren (5315) on Monday October 19, 2009 @07:45AM (#29792169) Homepage
        In the days of yore, people normally didn't run any audio servers at all.

        If they did, they either had a lot worse latency than PulseAudio currently has (arts, esound) or they drained laptop batteries much faster than PulseAudio currently do (JACK) or couldn't mix audio coming from different user accounts (JACK). All of them had worse backwards compatibility than PulseAudio.

        If they didn't, they could only have one application at a time play sound unless they had one of those relatively rare sound cards that had both hardware mixing and Linux support.

        A sound server is by its nature not a normal application. It has many somewhat conflicting requirements that just about no other type of application has to deal with. It's a userspace program that has to do a lot of things traditionally done in kernel space.

        As it's very sensitive to timing, realtime priority is optimal but not needed for a usable desktop setup. Ubuntu's default kernel doesn't even have full preemption enabled though. In 2009. Under those conditions you can't run something as timing critical as a low latency sound server reliably.
  • by Devlin-du-GEnie (512506) on Monday October 19, 2009 @06:24AM (#29791721)

    The sound on my =bare metal= install of Fedora 10 didn't work.

    After much forum-searching, config tweaking, and pounding-of-keyboard, I eliminated PulseAudio.

    The sound worked.

    Tell me again about PA's awesomeness.

  • computers are hard (Score:5, Informative)

    by Deanalator (806515) <pierce403@gmail.com> on Monday October 19, 2009 @06:29AM (#29791753) Homepage

    Sometimes mplayer will have sound, and totem will not, and other times, the opposite is true. Since the switch to pulseaudio, I have never seen a time when they both worked. Just a half hour ago there was no sound in miro. The volume slider in miro was turned up, the system volume was turned up, and my speaker volume was turned up. When I right clicked on my sound icon, went to preferences, and flipped to the "applications" tab, I found yet another volume slider labeled "miro" that was turned all the way down.

    A few months ago I bought new speakers and a new sound card because my sound stopped working. The new hardware still didn't work, and a few days later, I found some random profile or device or something that was muted, but to even see that menu I had to change the default device in some gui I had never seed before, and then change it back. Starting about a month ago, whenever I play a youtube video, sound will not work for anything but flash (even after I close firefox) until I killall npviewer.bin

    For some reason, when "surround" is muted on my laptop, my headphones don't work, but everything else does like normal, and if PCM gets muted, I will only get sound back if I turn the volume all the way down for a second, then turn it back up. Also, my USB headphones and USB speakers have never worked in linux.

    The new surprises with every upgrade is also pretty fun. It used to be that I could just do a killall "pulseaudio" then /etc/init.d/alsasound restart, and everything would be back to the old way of working, but recently it just breaks everything even worse, requiring a reboot to fix. I'm hoping that a clean wipe of everything, and installation of ubuntu 9.10 may magically fix some of these random idiosyncrasies, but I'm not holding my breath for it.

  • by petrus4 (213815) on Monday October 19, 2009 @06:39AM (#29791799) Homepage Journal

    I've looked at GNOME, I've looked at ALSA, (indeed, Ubuntu in particular in general terms) I've looked at the bloated instability of Compiz, I've looked at FreeBSD by comparison, (which I use on a daily basis) and at some of OpenBSD's source...and I've come to an important realisation.

    When it comes to both design philosophy and code quality, Linux developers suck; and I'm talking black hole level, here. The BSDs leave Linux so far behind that it isn't funny.

    What is even worse than the poor code quality, is the level of denial. The GNOME developers in particular have been told on numerous occasions what an abomination their baby is, yet they continue to insist on defending it, rather than actually listening to the feedback they are given, and trying to improve.

    The single main problem is what I called the Starbucks generation; self-righteous, latte-sipping yuppie CS graduates, who as said in another post, worship C++ and various hell-spawned forms of RPC, and use such to code bloated monoliths of a magnitude that would give Microsoft nightmares.

    They think they know better than the 30 years of UNIX experience that has come before them, including the very authors of the initial operating system itself.

    Although I haven't used Pulse, I have used ALSA, and I've used enough other Linux software to know that the Pulse author most likely shouldn't be defending himself; but should be humbly acknowledging that his software is terrible, and appealing to the community for help and insight into how he can do better.

    He can start by reading this [catb.org], and gaining a real appreciation of the system he is writing for.

    There are a lot of programmers in the Linux community who badly need some humility. They need to study the designers and authors of early UNIX; they need to learn how those people thought, and they need to emulate said designers' thinking and behaviour.

    Above all, more than anything else, there needs to be a return to implementation, rather than interface, simplicity. As priorities, faddishness, popularity, and most of all, the end user, need to die.

    • Re: (Score:3, Insightful)

      by jimicus (737525)

      There was some article on /. only a couple of weeks back about how communication is important in the real world and the general tone of many replies was "No it isn't".

      The fun bit is (and I'm sure it was unintentional), you've just proven the point beautifully. For example:

      The GNOME developers in particular have been told on numerous occasions what an abomination their baby is, yet they continue to insist on defending it,

      If the criticism is being levelled in those terms (and my own experience suggests it probably is), I'm not surprised. How many times in the whole of history has criticism in those sort of terms ever resulted in the person you're criticis

    • by Thalaric (197339) on Monday October 19, 2009 @08:30AM (#29792509)
      Wow, you managed to hate on Alsa, Linux, Gnome, C++ and the End User all in one post. Condolulations, this may be the most faddish post I've ever seen.
    • by turing_m (1030530) on Monday October 19, 2009 @08:51AM (#29792689)

      As priorities, faddishness, popularity, and most of all, the end user, need to die.

      Are you serious? Faddishness, I agree with. Popularity - popularity is something worth considering. Popularity implies community, and with a large community chances are most elements of a given problem have already been coded by someone else. Consider Perl and CPAN - a good reason to use Perl. But popularity is not enough to make me choose MySQL over PostgreSQL for instance.

      Lastly - the end user as a priority needs to die? That really depends on who you are writing the software for. If it's an operating system and you want it to compete with a Windows or OSX on some level, considering the end user is unavoidable. A vastly larger feature set and complexity than say, OpenBSD, is also unavoidable. Lack of time to audit the code and remove bugs to the degree that OpenBSD has done is also unavoidable. Maybe this goes some way to explaining the quality of the code and the size of the user base of both operating systems.

  • by OverflowingBitBucket (464177) on Monday October 19, 2009 @08:14AM (#29792363) Homepage Journal

    I've had three systems with audio problems. Two Ubuntu-based (8.04, 9.04), a third OpenSuSE-based. All with PulseAudio. All had oddities- ranging from the sound working only during X session startup/shutdown (and not in-between), through to the audio skipping, repeatedly, when changing the current desktop. These were on reasonably decent machines, by the way. Machines that should gobble up and spit this data so fast that it barely dents CPU usage.

    In each case, disabling PulseAudio and using, well, anything else, caused the problem to go away. OSS, ALSA, didn't matter, they both worked. Sometimes it was easy to remove PulseAudio, and sometimes it took a bit of work. Ubuntu 9.04 was a challenge. No, scratch that, it was a fight.

    I look around, I see horror stories and widespread problems with PulseAudio.

    I see claims that it works, if you configure it "properly". You know, I heard the same vague defence regarding Windows' instability. I didn't believe it for Windows either.

    I've heard that PulseAudio has a great set of features. However, I have no interest in digging into what these features might be. The core feature that I want above all else isn't supported by PulseAudio. That feature?

    Playing seamless audio.

    PulseAudio can't even get that right. Stutters and skips are the norm, audio systems that worked previously no longer do, and the backers of this abomination are in abject denial about it. There are widespread complaints about it across multiple applications and multiple operating systems, and still it "isn't configured properly". You can't be serious. Complaints about PulseAudio are not really shared by the majority of technical people? Oh, yes they are.

    If you want to provide a reasonable sound system, a *core* focus has to be on providing a working sound system. Get the core functionality right, then move onto features. Stability, correctness. Get the basics right. Also understand that API users may stuff things up, and falling over and dying is not the correct thing to do. The infrastructure needs to be resilient, not fragile.

    PulseAudio did *not* do this. Any of this.

    The order of the day seems to be to blame everything *but* PulseAudio. The apps are broken, the drivers are broken, the operating system maintainers didn't integrate it properly, it's not configured properly for the user's machine, the people complaining wouldn't be complaining if they were more technical, a lot of distros have adopted it so it must be good. Did I miss anything here? This has been the argument thus far.

    I'm going to be different. I'm not going to blame the developers, the applications, the users, the knowledge of the users, the operating system developers, or anyone else. I'm going to blame the one at fault, the *cause* of these problems. The one thing in common with this incredible list of problems.

    PulseAudio is completely and utterly broken- in design, in implementation, and in application. It is horrendous, shameful, and embarrassing.

Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer

Working...