Hacker News Reader

Comment by petepete | Hacker News Reader

PulseAudio posts are always filled with naysayers; the vast vast vast majority of users (like systemd in this regard) have no idea it's even running and just get on with whatever they're doing.

I've primarily run Linux over the last fifteen or so years and barely had an issue that's directly PA's fault.

I remember the bad old days where a playlist would finish and then GAIM's notification sound would bleat fifteen times. PA saw an end to that.

View on HN

Firefox stopped supporting ALSA, so I had to install PA. PA gives me: a noise chirp when the PA daemon starts, which is probably some uninitialized garbage buffer. Sometimes (I don't know what triggers it, seems to be random, and no, it's not the auto-suspend module which is on by default but seems to cause a similar bug for many people) audio starts to lag by .3-.5 seconds. Restarting PA does not help; have to reboot, which I can't/won't do for days at a time. This is supposed to be a Linux system, not Windows 98.

I don't hate PA. On another machine it was always installed. But it is quite clear to me that it is yet-another layer on top of the existing infrastructure, so it statistically will cause more issues than just the infra that's there already.

The problem with PA is that (it appears like) there aren't really any simple errors. For most software, you have a bunch of common problems that you can find on Stackoverflow easily with a reliable solution.

Pulse, on the other hand, while working fine on 99% of systems, usually fails catastrophically in creative ways on the remaining 1% and it's really hard to even understand what the problem is. (And of course, these 1% will shape public opinion. A large portion of the 99% is not even aware they're using Pulse.)

Two nines isn't very many nines. I've had problems with PA 100% of the time. Must be me, right? The only PA solution I know is purging it from my system.

what people mean when they say the vast majority of people dont have problems is "I don't care about your objectively broken experience"

Yeah, I've certainly had to learn a few tricks to debug audio issues on my Linux systems. Last one was a crash when disconnecting Bluetooth headphones, traced to PulseAudio unloading its Bluetooth plugin from code within the plugin. You don't get a backtrace if the crash is from returning into code that doesn't exist anymore. I still haven't figured out why this didn't cause crashes on all systems.

Factors which will have majorly affected people's PulseAudio experience over the years include audio hardware, what software they use with it, system uptime, local RF interference, use of suspend/resume, which patches their distro backported, and the exact stack and heap layout of the process on their system.

You should install apulse and run that with Firefox! Works like a charm.

You can also compile FF with ALSA enabled. Gentoo has a useflag for that.

This is the better option (aside from fixing your PA config in the first place, which I'd heavily recommend instead). apulse can get into issues with Firefox's sandboxing. It supports PulseAudio and works with ALSA too, but ALSA-pretending-to-be-PA won't work.

But really, fix your PulseAudio instead.

In theory yes. But compiling Firefox is just a mess.

./mach bootstrap && ./mach build

You can just use your distribution's package manager for that.

I thought they had plans to deprecate the build flag in a later version, but can't find verification.

It will in any case not get any maintenance, so expect things to break with no recourse as new versions are released.

This similar to how on paper Firefox can still be compiled with GTK2, but it is not supported.

> Restarting PA does not help; have to reboot

Then PA is not the problem, your sound card/drivers is.

How does one go about debugging something like this to pinpoint the root cause? I am just curious. I know nothing about PA (or even sound). Thanks!

How to debug PulseAudio problems

https://fedoraproject.org/wiki/How_to_debug_PulseAudio_probl...

Thanks! I just skimmed through this and discovered strace -k (Print the execution stack trace of the traced processes after each system call). TIL

> Firefox stopped supporting ALSA, so I had to install PA

PulseAudio emulation for ALSA https://github.com/i-rinat/apulse

> I remember the bad old days where a playlist would finish and then GAIM's notification sound would bleat fifteen times. PA saw an end to that.

I too used Linux at that time and I remember that problem. The workaround in those days was to use esound. IIRC it also disappeared by the switch to alsa.

FreeBSD also doesn't have this problem, and it's still using the OSS api. Let's not confuse API with implimentation.

For me, personally, the bad old days before PA was OSS, when an application could squat on the audio hardware and absolutely disallow any other software from playing any sounds at all on the system until it was stopped or forcibly killed. And good luck finding which piece of software was claiming absolute ownership of your sound card.

PA gives me the ability to have multiple pieces of software making noise at once, a software mixer with per-application and per-sound-hardware volume control which is completely divorced from those applications (so if I say MUTE, it is damn well MUTED), and the ability to choose where the sound is being output to. I cannot imagine anything doing better on the hardware I have.

Completely skipped ALSA and configuring DMIX, I guess? That at least provided software mixing.

To be more precise, that was the state of affairs with OSS on Linux. On FreeBSD, for example, the same OSS API has been providing transparently multiplexed output for many years. I don't even know how long, but I recall it already being there when I was fighting with dmux.

Perhaps not coincidentally, the primary sound API on FreeBSD is still OSS.

I usually had sound cards with hardware mixing, but what was wrong with esd? It did software mixing and seemed to work. (And didn't require you to run the rest of enlightenment, despite the name)

Oh, it did not work good for many use cases, and even in the supported use cases it had pretty severe bugs. PA is also way more power efficient.

Never mind that ESD and like is a leftover from the OSS days. Alsa has its own sofware mixer, dmix, that these days can be transparently inserted when the underlying hardware do not offer hardware mixing.

I wonder of Linux's biggest problem these days is the amount of "herd knowledge" that is floating around that is obsolete to say the least, yet is being used to justify some dev's latest weekend glory project.

> Never mind that ESD and like is a leftover from the OSS days.

I never had many problems with OSS either. :) I'm bringing up esd because I was misrembering that when pulseaudio came on the scene, it seemed to be already existing, not screwing up too badly, and addressing the commonly held up use case of software mixing.

After reading notalaser's fine summary [1], I'm realizing I've lumped 'ALSA broke everything that I already had working (but did eventually work, and support newer hardware)' and 'PulseAudio broke everything that I already had working' together in time in my mind, when really things were many years apart. It seems that by the time PulseAudio came out / was widely pushed, ALSA had already subsumed esd (unless you were using the network audio features), so the most often reported 'great thing' doesn't sound like something people wouldn't have had.

[1] https://news.ycombinator.com/item?id=13382152

I remember when PulseAudio came out. I loved it! I could actually have two programs open playing audio at the same time[0]. The future was now.

[0] If I remember correctly, this was due to driver issues, but somehow PA just handled it.

Old versions of ALSA only supported one input, but that's been a solved problem for a decade.

At least.

Older versions supplied dmix but didn't automatically enable it. Newer versions are supposed to autoenable it on audio devices without hardware mixing.

Frankly the only thing PA brought to the table was the ability to handle multiple audio devices while there is ongoing audio IO. Primarily in relation to usb headphones/headsets. But then that class of hardware is its own kind of abomination in the first place.

PA still randomly dies on my Thinkpad T420 running Ubuntu 17.04. I have to manually restart it several times in a day, and now I am really thinking of switching to a systemd/pulseaudio/RedHat influence free distro.

Try Debian on it, half the reason I switched away from Ubuntu years back was that it always seemed to have show stopping bugs like what you've experienced. I've yet to have PulseAudio crash on my T420, though sometimes it buffers audio when I walk too far from my bluetooth speaker.

What gets me though, is I never had a problem with Pulse Audio until I installed systemd.

Reply on news.ycombinator.com