Wednesday, July 9, 2008

More PulseAudio Problems

I reinstalled PulseAudio to try and resolve the plethora of problems I've been having with it (that and openSUSE 11 doesn't actually ship th esound daemon anymore, so if I want full audio support I have no choice but to get the pulse-esound-compat package working short of forking the distro and maintaining my own set of esound/gnome/etc packages which is not my idea of fun).

Unfortunately, this has resulted in countless hours of frustration. After having read and followed the instructions at, it turns out that is exactly how my system was already configured. So no help there.

I don't know what the deal is, but I constantly have problems with PulseAudio.

For example, earlier today I was having an IM conversation with a friend in Pidgin and it locked up. I restarted Pidgin, but I wasn't getting audio events anymore. *shrug* Oh well.

At some point later I navigated my firefox window over to youtube to link a friend to some video. No surprise here, I get no sound and in fact, the flash video pauses as soon as the sound was supposed to start (which is a few seconds into the video).

At this point I close firefox and decide to reload it, thinking maybe that will solve it. Nope, I was wrong. Instead, firefox hangs before any windows pop up. Great.

Since I got flamed last time I blogged about PulseAudio for issuing a `killall -9 pulseaudio` command (btw, pulseaudio appears to have a --kill command-line option), I figured I'd log out and log back in again instead... but this was not to be. Instead, my desktop locks up (presumably because of the logout.wav).

Ok... so I Ctrl+Alt+F1 to the console, login as root, `init 3; init 5`. Since my system is configured to auto-login, when X came back up it tried to log me in. Instead, I get a hang.

Good grief, I guess I have no option but to reboot so that's what I do.

In the interest of saving other people from this catastrophe, I grabbed libgnome out of svn and wrote up the following patch to prevent it from hanging whenever PulseAudio decides to misbehave (which it seems quite prone to do).

Index: libgnome/gnome-sound.c
--- libgnome/gnome-sound.c (revision 3750)
+++ libgnome/gnome-sound.c (working copy)
@@ -30,8 +30,12 @@
 #include <stdio.h>
 #include <stdlib.h>
+#include <sys/types.h>
 #include <unistd.h>
+#include <fcntl.h>
+#include <errno.h>
 #include <time.h>
+#include <poll.h>
 #ifdef HAVE_ESD
 #include <esd.h>
@@ -413,6 +417,55 @@
+#ifdef HAVE_ESD
+static int
+send_all (int fd, const char *buf, size_t buflen)
+ struct pollfd pfd[1];
+ size_t nwritten = 0;
+ int flags, rv;
+ ssize_t n;
+ if ((flags = fcntl (fd, F_GETFL)) == -1)
+  return -1;
+ fcntl (fd, F_SETFL, flags | O_NONBLOCK);
+ pfd[0].events = POLLOUT;
+ pfd[0].fd = fd;
+ do {
+  do {
+   pfd[0].revents = 0;
+   rv = poll (pfd, 1, 100);
+  } while (rv == -1 && errno == EINTR);
+  if (pfd[0].revents & POLLOUT) {
+   /* socket is ready for writing */
+   do {
+    n = write (fd, buf + nwritten, buflen - nwritten);
+   } while (n == -1 && errno == EINTR);
+   if (n > 0)
+    nwritten += n;
+  } else if (pfd[0].revents & (POLLERR | POLLHUP)) {
+   /* we /just/ lost the esd connection */
+   esd_close (fd);
+   fd = -1;
+   break;
+  } else if (rv == -1 && errno == EBADF) {
+   /* socket is bad */
+   fd = -1;
+   break;
+  }
+ } while (nwritten < buflen);
+ if (fd != -1 && flags != -1)
+  fcntl (fd, F_SETFL, flags);
+ return fd;
  * gnome_sound_sample_load:
@@ -469,21 +522,23 @@
     * file, or event type, for later identification */
    s->id = esd_sample_cache (gnome_sound_connection, s->format, s->rate,
         size, (char *)sample_name);
-   write (gnome_sound_connection, s->data, size);
-   confirm = esd_confirm_sample_cache (gnome_sound_connection);
+   gnome_sound_connection = send_all (gnome_sound_connection, (const char *) s->data, size);
+   if (gnome_sound_connection != -1)
+     confirm = esd_confirm_sample_cache (gnome_sound_connection);
    if (s->id <= 0 || confirm != s->id)
        g_warning ("error caching sample <%d>!\n", s->id);
        s->id = 0;
-   g_free (s->data);
-   s->data = NULL;
   sample_id = s->id;
-  g_free(s->data); g_free(s);
+  g_free(s->data);
+  g_free(s);
   return sample_id;
@@ -521,9 +576,12 @@
   sample = gnome_sound_sample_load (buf, filename);
-  esd_sample_play(gnome_sound_connection, sample);
-  fsync (gnome_sound_connection);
-  esd_sample_free(gnome_sound_connection, sample);
+  if (gnome_sound_connection != -1 && sample > 0)
+    {
+      esd_sample_play(gnome_sound_connection, sample);
+      fsync (gnome_sound_connection);
+      esd_sample_free(gnome_sound_connection, sample);
+    }

This patch should hopefully help prevent the typical gnome apps from hanging when trying to play audio, but I don't really have any surefire way of testing that it actually works.

Update 2008-07-10 10:42am I've now also written the following patch for libesd so that it doesn't hang for god knows how long when trying to open a connection to the sound server (in my case, pulse-esound-compat):

diff -up esound-0.2.38.orig/esdlib.c esound-0.2.38/esdlib.c
--- esound-0.2.38.orig/esdlib.c 2008-07-10 10:10:31.000000000 -0400
+++ esound-0.2.38/esdlib.c 2008-07-10 10:32:23.000000000 -0400
@@ -20,9 +20,11 @@
 #include <arpa/inet.h>
 #include <errno.h>
 #include <sys/wait.h>
+#include <poll.h>
 #include <sys/un.h>
 #ifndef SUN_LEN
 #define SUN_LEN(ptr) ((size_t) (((struct sockaddr_un *) 0)->sun_path)  \
                      + strlen ((ptr)->sun_path))
@@ -408,6 +410,43 @@ int esd_resume( int esd )
     return ok;
+static int
+connect_timeout (int sockfd, const struct sockaddr *serv_addr, size_t addrlen, int timeout)
+ struct pollfd pfd[1];
+ int flags, rv;
+ if ((flags = fcntl (sockfd, F_GETFL)) == -1)
+  return -1;
+ fcntl (sockfd, F_SETFL, flags | O_NONBLOCK);
+ if (connect (sockfd, serv_addr, addrlen) == 0) {
+  fcntl (sockfd, F_SETFL, flags);
+  return 0;
+ }
+ if (errno != EINPROGRESS)
+  return -1;
+ pfd[0].fd = sockfd;
+ pfd[0].events = POLLIN | POLLOUT;
+ do {
+  pfd[0].revents = 0;
+  rv = poll (pfd, 1, timeout);
+ } while (rv == -1 && errno == EINTR);
+ if (pfd[0].revents & (POLLIN | POLLOUT)) {
+  /* success, we are now connected */
+  fcntl (sockfd, F_SETFL, flags);
+  return 0;
+ }
+ /* took too long / error connecting, either way: epic fail */
+ return -1;
  * esd_connect_tcpip: make a TCPIP connection to ESD
  * @host: specifies hostname and port to connect to as "hostname:port"
@@ -512,7 +551,7 @@ esd_connect_tcpip(const char *host)
            goto error_out;
-         if ( connect( socket_out, res->ai_addr, res->ai_addrlen ) != -1 ) 
+         if ( connect_timeout ( socket_out, res->ai_addr, res->ai_addrlen, 1000 ) != -1 ) 
          close ( socket_out );
@@ -596,9 +635,9 @@ esd_connect_tcpip(const char *host)
     socket_addr.sin_family = AF_INET;
     socket_addr.sin_port = htons( port );
-    if ( connect( socket_out,
-    (struct sockaddr *) &socket_addr,
-    sizeof(struct sockaddr_in) ) < 0 )
+    if ( connect_timeout ( socket_out,
+      (struct sockaddr *) &socket_addr,
+      sizeof(struct sockaddr_in), 1000 ) < 0 )
  goto error_out;
@@ -650,8 +689,7 @@ esd_connect_unix(void)
     socket_unix.sun_family = AF_UNIX;
     strncpy(socket_unix.sun_path, ESD_UNIX_SOCKET_NAME, sizeof(socket_unix.sun_path));
-    if ( connect( socket_out,
-    (struct sockaddr *) &socket_unix, SUN_LEN(&socket_unix) ) < 0 )
+    if ( connect_timeout ( socket_out, (struct sockaddr *) &socket_unix, SUN_LEN(&socket_unix), 100 ) < 0 )
  goto error_out;
     return socket_out;

Hopefully after these 2 patches get applied, my system at least won't become unusably hung when pulseaudio decides to crap out on me, but these patches doesn't solve the root of the problem :(


sssk said...

Amen to that!

I too have been fed up with the issues with pulseaudio. But, I happily kill -9 the process and get along with it.

Jeffrey Stedfast said...

Yea, I started off doing that but in the interest of making openSUSE w/ GNOME (KDE doesn't use pulseaudio) not suck (especially since I work for Novell, even though I'm not on the OS or desktop teams), I've been trying to "use" pulseaudio so that I can find/bitch-about/fix the problems with it.

Basically, if I want something done right, I gotta do it myself :\

My other option is of course ripping out pulseaudio and then maintaining an esd package along with some forked gnome packages, but that doesn't sound like a whole lot of fun.

jcdubacq said...

Do you have libflashsuport installed? It is necessary for flash+pulseaudio. I once wrote an install guide for debian+amd64 of libflashsupport.

That said, every time I had trouble with pulseaudio, it was because of an application trying to access the sound device or alsa bypassing pulseaudio. Now everything works fine if I take care that every sound application uses pulseaudio.

Anonymous said...

I've installed 30 or 40 Hardy desktops with PulseAudio on various hardware configurations, and have had no complaints or reports of sound trouble.

Rather than slinging mud at the entire PulseAudio project in public, why not get involved? If you're competent enough to hack together a patch and post it on your blog, you're competent enough to help nail down the corner case you're experiencing.

Try directing your effort towards helping to solve the problem. You'll get a working system, and the rest of us won't have to grit our teeth reading that PA is completely broken - just because it doesn't work well for you.

Anonymous said...

Wow. None of my PCs running Ubuntu have any of these issues, and they all use PA. Perhaps the PA integration in SUSE just plain sucks? I've found PA to be quite good and stable on the desktop, and even in embedded systems!

Anonymous said...

"openSUSE 11 doesn't actually ship th esound daemon anymore"
esound-0.2.38-75.1.i586.rpm has a /usr/bin/esd file...

Anonymous said...

The issue between Flash, Alsa and Pulse is a known one that seems to be mostly located in Flash, and hence is rather difficult for anyone except Adobe to resolve :\. Ironically it's actually part of the reason why many distros are adopting Pulse: we figure if everyone is using Pulse and complaining when Flash audio breaks, it'll pile on the pressure on Adobe to do something about it...

the Mandriva write-up is here:

as it suggests, you can try using Gnash or swfdec, if they're suitable for your needs, but otherwise the only options are to live with the bugginess, live without Flash, or live without Pulse.

jacksonh said...

Dude you are awesome. I would say like 15% of the world is actually non-lazy enough to blog about something like this. Then you have maybe 3%-4% of those people that might actually try downloading the source to see what the hell is going wrong. I can't even imagine what the odds of people patching gnome for this are.

Anonymous said...

I have been using OpenSuse 11 from the release date, and I have been using multimedia/audio applications constantly. I have not had one single glitch with Pulseaudio so I'm wondering what customizations you did into your distribution when you installed it...

Remenic said...

I'm happy (and sad, both at the same time) to see that I'm not the only one with PulseAudio problem. I have them on my Ubuntu 8.04 installation, and it's awfully annoying.

killall -9 works fine indeed, but I really wonder how this got through the QA, if such a thing even exists at Ubuntu.

Maybe it's my sound card that doesn't play nice with PulseAudio, but I never had any problems with Ubuntu 7.10. So everytime my sound hangs, I keep wondering why they switched from something that worked, to something that works sometimes.

Anonymous said...

I believe your problems with firefox and flash come from an outdated libflashsupport. I had this problem too on Debian Sid after I upgraded to a newer flashplayer as 9.0.48 or so. The solution for me was to install a newer version of libflashsupport (the package is flashplugin-nonfree-pulse in Debian).

Get it here:

Jeffrey Stedfast said...

yes, I have libflashsupport

Jeffrey Stedfast said...

Anonymous: did you even read my blog? I'm trying to fix the problems with PulseAudio.

But why should I have to get involved? It should already work. It worked fine before with just ALSA, why shouldn't it now? This is a regression.

Not to mention I have plenty of other things to do in my time beyond fixing PulseAudio bugs (like, oh, my full-time job which is not "fixing PulseAudio bugs", my hobbies which does not include "fixing PulseAudio bugs", etc), but unfortunately now I have no choice but to futz with it because it's a constant annoyance that pisses me off.

If this was a piece of software that I actually had a choice in using or not, then I'd just toss it and move on (wouldn't even waste time ranting about it), but unfortunately that's not easy to do with PulseAudio because it is replacing ESounD (another quality product, but at least it worked) in every distro under the sun and unless I want to maintain my own distro for the rest of my life, I have no choice.

This angers me because I have little free time and now I'm being forced to fix PulseAudio because the people pushing it didn't see fit to make it robust before shoving it down everyone's throats. Even the author says it's not ready for public consumption on one of the GNOME mailing-lists (I think desktop-devel-list?), but that didn't stop people from forcing it on me.

The comments on my last blog suggested that all the distros were pushing PulseAudio in the hopes of exposing these sorts of bugs so that could be fixed. Why, what a brilliant idea! Lets piss everyone off by forcing them to be beta testers!


Jeffrey Stedfast said...

Hmmm, I tried installing esound yesterday with zypper but it turned out that the esound package was an alias for pulse-esound-compat.

I'll try searching for esound for an actual esound package (or do you have a link handy?). Thanks for the tip.

Jeffrey Stedfast said...

Ironically it's actually part of the reason why many distros are adopting Pulse: we figure if everyone is using Pulse and complaining when Flash audio breaks

AdamW: This is precisely the behavior that rubs me the wrong way.

Good to know that your users are just a pawn to be sacrificed in order to force Adobe's hand.

Jeffrey Stedfast said...

I haven't made any customizations to my installation of openSUSE 11 - certainly none involving audio.

It's a vanilla install of openSUSE, the -devel and -debuginfo/debugsource packages for the lower half of the GNOME stack / xulrunner so that I can get useful backtraces, and development tools.

Heck, I've done so little customization that every desktop application on my system is using the default settings other than Evolution (since I had to give it my email accounts) and my gnome-terminal (I like grey-on-black - which is why I submitted a patch to make it do that years and years ago). In fact, my desktop still has the same background it did when I installed it.

Jeffrey Stedfast said...

A number of people seem to be pointing the finger at Flash, here, but I think they missed that I was having problems even before I visited a Flash-enabled site (e.g. youtube in this case).

Jeffrey Stedfast said...

I seem to have libflashsupport-000-67.1

I have no idea how recent it is, but I would imagine fairly recent as openSUSE 11 was only released a month or 2 ago.

Anonymous said...

Two ideas:

a) What audio hardware and driver are you using? Maybe there's a bug in that driver that Pulse just happens to trigger.

b) Lots of people with Ubuntu or Fedora claim PA works, but you're on OpenSUSE. Maybe the PA package in OpenSUSE is outdated, has a bad patch, is miscompiled, or something? God knows that kind of stuff does happen time to time. (Hello Debian/OpenSSL! ;) I know in Fedora 8 I'd have very occasional PA crashes, but that doesn't seem to happen in Fedora 9 ever. Either an updated kernel, updated ALSA, or updated PA fixed whatever the issue was.

Jeffrey Stedfast said...

a) I'm on a Lenovo T61 laptop - afaik, intel sound card along with intel pretty much everything else hardware (including graphics chipset).

b) the PA that openSUSE 11 is using is the latest 0.9.10 and of the 3 patches applied to it, 2 of them are from upstream and 1 changes some default values in the daemon.conf file.

I'll try changing them back to the upstream defaults I guess.

Anonymous said...

Jeff, well, it's more complex than that. Everyone's known for years that we're going to need to pick a sound server and use it. Before Fedora pushed the boat out with PulseAudio, this had been known for years but no-one was doing anything about it.

You say the previous situation "worked", but that's a simplification. It worked for you, but it was really not an acceptable system and it didn't work for a lot of people. esd was crap, and it was unmaintained. It may have worked for you, but others had a lot of problems with it - just like Pulse.

At least now all the major distros have gone with Pulse, everyone knows where things are going and what they need to do: make their app play nice with Pulse. For the two or three years previous, all anyone did was whine about how terrible Linux audio is, which wasn't really very productive. At least now people are aiming to fix it.

Still, in Mandriva, we did go to the trouble of coding a big happy "Disable Pulseaudio" button. Isn't there one in SUSE?

Martin said...

My system wide PulseAudio server hangs every night. It's working when I go to bed and it's dead when I get up. "killall -9 pulseaudio" is now a part of my morning ritual.

Jeffrey Stedfast said...

AdamW: why do we need a sound daemon process? AFAIK, ESD was only ever written because at the time software mixing was not a solved problem. Now it is in ALSA and (even better) in OSS in the kernel.

Running a sound server is a gross hack that only makes the entire linux desktop sound architecture more likely to fail (it just adds more points of failure).

The only time it's needed is if you need to redirect sound to another machine on the network - but that can be as an addon rather than part of the core.

There's no reason any application should be sending wav data over the wire to a local sound daemon just so it can dump it to the kernel's audio driver. That's just ridiculous.

Applications should use a simple sound library for sending audio data directly to the kernel driver (where it should be mixed if needed) before being passed to the hardware itself.

Audio mixing does not belong in a userspace daemon process, especially one that is unreliable in that it likes to hang.

It frustrates me that people like to solve problems by making a mountain out of a mole hill and over-architecting everything (which just makes things less reliable, bloated, etc).

Thomas said...

By the same token, there's no reason any application should be sending image data over the wire to a local display daemon just so it can dump it to the kernel's video driver. That's just ridiculous.

Anonymous said...

I understand the frustration with the bugs, which seems suse-specific. But ranting against FINALLY getting sound fixed in Linux just because there are some bumps? You must really not have actually used sound in Linux earlier. It was never solved, not with Alsa+Dmix, not ever. Read. Up. On. Why. Pulse. Hint: it has very little with moving streams between computers and mixing. Just go read. Now.

Anonymous said...

"Now it is in ALSA and (even better) in OSS in the kernel."

Except that they're not. dmix introduces lags, clicks, and other audio glitches for a lot of people in a lot of circumstances because the in-kernel mixing is (for good reason) very simplistic.

They don't allow dynamic real-time changing of output devices, such as when I plug in a USB headset.

They don't allow sound font caching across multiple processes, meaning that a simple sound theme in GNOME without Pulse (or ESD) could introduce a huge memory spike or excessive audio I/O every play (leading to pops and clicks under load).

They don't do a lot of things that Pulse does and that people actually need.

In your first post on the topic, you mentioned how mad people would be if you introduced your new IMAPv4 provider to Evolution. Sure, early tech previews can be a drag. But on the other hand, you DID write a new IMAPv4 backend, even though quite a few people will happily claim that Evolution's current IMAP support "just works" right now. Moral of the story? Just because you don't see the problem doesn't mean it's not there.

Yes, it sucks you're hitting these problems. They NEED to be fixed. But you have to help, because (obviously) whatever specific issue is causing these problems for you simply aren't happening for the PulseAudio developers. You should know as well as anyone that you can't fix a bug you can't find. If PulseAudio daemon is hanging, try getting some stack traces from GDB, SystemTap output, or _something_ to send to the PA developers. Make sure you give them extensive hardware information dumps (there are multiple revisions of every laptop model, including the T61, so the model number isn't enough - specific chip IDs helps more). The bug you filed has already been classified as a blocker - the developers care, make no doubt.

Jeffrey Stedfast said...

I'm not a fancy sound user, but I've grown to expect things like music players (e.g. banshee or rhythmbox or xmms) to work, login/logout wavs to play, and flash sound to work.

Unfortunately, now that my system uses PulseAudio instead of ALSA/ESD, I've had nothing but problems.

Everyone keeps saying "sounds like an openSUSE-specific bug" but searching through the Ubuntu forums or talking to friends working at VMWare who use Fedora, it's quite clear that many of the problems I am experiencing are not openSUSE specific.

I agree that sound on Linux has not historically been great, but it worked in the most basic sense for everyone I knew, but now everyone I know has problems no matter what distro they use.

wdomburg said...

"why do we need a sound daemon process?"

"Now it is in ALSA and (even better) in OSS in the kernel."

Erm, dmix *is* a sound daemon process. The only time ALSA precludes a sound daemon is if you have one of the relative few cards that has support for hardware mixing and a driver which takes advantage of it.

Jeffrey Stedfast said...

What's the name of the ALSA dmix daemon process? I don't see it in my ps list on an older box w/o PA (and I doubt I have one of the fancy cards with hw mixing).

wdomburg said...

"What's the name of the ALSA dmix daemon process?"

Whatever process first opens the audio device gets forked; subsequent processes deliver streams to that process via shared memory.

Tshepang Lekhonkhobe said...

Jeffrey: It's unfortunate that you get to the point where you critisize the whole userspace sound-server idea instead of focusing on your bug report. I complain because Anonymous explained why that approach is 'superior', and instead of acknowledging her points, you simply retort to your bug report. Point is, simply because you got pissed by PA bugs don't mean what PA represents (userspace sound-servers) is non-sense.

Oh, and it also looks like you haven't read Lennart's blog/mail posts.

note: PA's maturity is another issue of course, and haven't used it enough to comment.

alankila said...

As a developer who hacked a pulseaudio client using the "simple" interface, literally no more than a few calls, I am very unimpressed.

It doesn't work. The pa_simple_write() call accepts a pointer of sound data and length of that buffer to write. And guess what? Only buffer lenghts in the 2048 - 8192 range actually appear to work. (Audigy 2 ZS as hardware.) Anything else and I get skips and jumps in the playback. Absurd.

Even today, writing exactly 4096 byte buffers to that piece-of-shit sound server, I sometimes hear the audio jump. On an dual-core system. This is so crappy it's not funny.

I would _love_ to use the ALSA-to-Pulse bridge thingy that you can enable with a few lines in .asoundrc but that doesn't work either. Let me qualify that. Like, you might hear the audio play without your whole damn application freezing up when a simple buffer underflow happens because Linux scheduler did not see fit to give enough CPU time to your app.

And when that stupid pulseaudio demon hangs, like it semireliably does when I'm seeking in audacious using the cursor keys, the whole daemon and any clients using it have to be killed and restarted. And it does this semiregularly, on laptop with intel hardware I resurrect the bloody thing every second day or so.

I fucking hate pulseaudio at this point. With this kind of show so far, it is irrelevant how great it is at some random point in the future. Can't we just get software that works? Users do not want to be betatesters any longer. If open source can't produce working code without pushing shit to masses, maybe it is a failure as a development model.

Pulse defenders say that ALSA's dmix might have been atrocious in so many ways, but I never noticed a thing: honestly, ALSA's dmix Just Worked. Something I can't say Pulse to do.

Marcus said...

Jeffrey, I think you got it exactly right about the complications added by making pulseaudio a networkable sound daemon. In my experience with Ubuntu 8.04, Suse 11, Fedora 9 (note, all latest versions) pulseaudio and sound in general is broken and is the biggest single flaw in linux on the desktop today.

The bit that really gets me is that it seems quite obvious and clear (read some of the mailing lists) that the pulseaudio developers are simply not up to the task of creating the next attempt at fixing sound on linux. Nor was the vetting process at any of the distributions listed complete enough to catch very obvious problems in pulseaudio.

It's a really bad situation. I personally believe that pulseaudio alone has pushed linux several years backward as a viable desktop platform for non-expert home use.

The anonymous commenters railing against you while not even displaying their name(s) should be ashamed of themselves, pulseaudio is an enormous threat to linux being dominant in the home. A few google searches show just how bad it is, for example, "ubuntu pulseaudio problems" returns 432,000 results. It's helpful to compare this with other keywords to get a sense for just how much pain and suffering has been caused by the Fedora/Ubuntu/Suse et al decision to guinea-pig us all.

The biggest copout on earth is the blame-game against Adobe. That's bull manure when Flash is the single biggest media force in the world. You don't make a 600 pound gorrilla play ball because of some high faluting tripe. You feed the goddamned gorrilla whateve the fck it wants. Either that or you just get out of the gorrilla business because you're ruining linux' domination path with your snivelling incompetent p.o.s. sad excuse for a software stack.

Religious zealots should stop reading here, but for the good ol' athiests among you where the fck did you forget about survival of the fittest? I mean come on, seriously, if you're in this to win then you're gonna do whatever it takes to win. This is why we have GW for prez, because he knows all about survival of the fittest, so get off of the high horse and just fix the bloody problem already, which in this case means, dumb this goddamn garbage pulseaudio software down to do what its freaking supposed to do, which is make audio on the desktop WORK not proclaim some unfit psuedo-egalitarian tripe.

Jeffrey Stedfast said...

The bug you filed has already been classified as a blocker - the developers care, make no doubt.

You might want to note that I marked them as blockers, not the developers. The developers haven't even bothered to look at my bugs yet afaict.

Anonymous said...

First thing i do after Ubuntu/SuSE/Fedora/whatever installs is deinstalling any installed soundserver. ALSA has support for software-mixing and does this just fine out-of-the-box on any soundcard i had. So no need for a soundserver on desktop-installs.

Stan The said...

The first thing i did on my Ubuntu was to fix the pulseaudio binary with 'sudo gimp /bla/bla/pulseaudio'. Then use a big red marker and write "die die DIE!!!!1"

Fuz Master? said...

Does anybody know if Ubuntu has recently changed something to cause PulseAudio to hang? I've never had any trouble with it until the last two days. Then, out of the blue, it apparently hangs and all my media apps hang thereafter. I finally traced it down to 'pulseaudio' using lsof and grep. And yes, 'kill -9' seems to be only a temporary solution to this annoyance.

Anonymous said...

Why oh Why can't pulseaudio have a nice integrated little gui that just autoconfigures the damn thing for your system based on your requirements??
I've used SUSE a few years and had no trouble with sound until pulseaudio.

Anonymous said...

as a linux user since god knows when, i experienced the OSS fun, then alsa came along and since about 2006 alsa has worked like a dream, i thought the nightmares over, then along comes pulseaudio, which i fixed by purging a system of anything related to it, but i hear gnome 2.28 is going to have pulseaudio completely entrenched? i may have to try KDE again for the first time since 2001

Frédéric said...

As of Ubuntu 9.10 Karmic Koala, yes Pulseaudio seems more entrenched in Gnome, but it still works with it removed from the system (using synaptic).
I lost the mixer controller though, but not the settings I have done before removing Pulseausio (!). I guess I would need to reinstall Pulseaudio if I need to change my mixer settings, or found the Alsa mixer controller (which seems to be no more installed by default).
Pulseaudio seems to improve with time, now microphone works with it. But sound from Wine apps still remains chopy, so good bye Pulseaudio.

For the guys blaming on people complaining about Pulseaudio, sorry but I can not agree with you. Me too, I was not getting so many troubles with Alsa. The move to pulseaudio was too early. It has cause much problems to many users, without giving them new features they were actually caring of.

Prior to Pulseaudio, I was having fine sound for my usage with few steps after the install (some wine cfg were needed for me). Now I always need to add to my sound setting up the step of getting rid of Pulseaudio. At each Ubuntu upgrade, I try to get Pulseaudio working. It gets better, but still not as good as what do Alsa for me.

And it looks like that's the case for many users.
Conclusion : Pulseaudio still not enough mature for being the default ?
My answer is yes, for now.

So bad, the Pulseaudio bad moved is also done on other subjects. Let's say, polkit gnome policies... Upgrade after upgrade, I have more security tuning to do to get my desktop doing what I want... And it get even more complicated since they have discontinued the GUI to set up polkit gnome policies. And moved some settings in others software layers. Cool to have to track down were things have gone every six months...
Not to say no change should occurs, but at least where thing has got removed, some help text/links should be left to say were it is gone, or how to handle that now... Of course it is time consuming, but it is mandatory to avoid discouraging casual users of using Linux.

In the past I was thinking Linux would one day get enough user friendly for anyone. I am no more thinking it.

Tshepang Lekhonkhobe said...

I agree that PA is getting better but hasn't matured yet. In my case, on my Debian Squeeze, it consumes way too many CPU cycles, so got rid of it and reverted to ole stuff -- luckily Debian wasn't so rush as to get rid of the alternatives.

Anonymous said...

The snivelling and excuses are pathetic. I think Mr. Stedfast has been vindicated (if not by his 20K+ commits) by the years that have gone by with no resolution to the problem. PA has been crud for years now.

I thought I would dip my toe back into the Ubuntu world, trying to set my house up for Apple TV home media what-not. Everything is up in the air. I also want to get back into desktop music, Audacity, etc.

This weekend has been spent tracking down various fruitless non-solutions to the same fscking problem with nasty crackling audio, and I'm on Ubuntu 11.04.

The one time I was able to get esound installed, the system came back up with crystal clear sound and NO NETWORK. This is ****.

I don't mind working along with a FREE system, but this has become a crusade, a death march, and I'm out.

Thank you Mr. Stedfast; your head must hurt banging it on the wall of willful ignorance.

Code Snippet Licensing

All code posted to this blog is licensed under the MIT/X11 license unless otherwise stated in the post itself.