Hacker News Reader

Comment by na85 | Hacker News Reader

>Who needs features anyway.

Can you name a single feature or use case addressed by PulseAudio that isn't addressed by ALSA?

Unplugging my headphones and letting other people be able to hear what I'm listening to? I mean, with ALSA I can shut down whatever program I'm using, switch to speakers from headphones, then start the program up again but that's a bit cumbersome. Maybe it is possible with ALSA somehow but not with the programs and distros I'm familiar with. When PulseAudio came out all of a sudden Linux went from less convenient to use headphones and speakers with than Windows to distinctly more convenient.

I never had a laptop where plugging in headphones didn't disable the speaker (and nothing I could do about that in software).

If that really is the case you could use dmix and have audio played on both the headphone and speaker output. You would still have to mute the speakers when plugging in the headphones though.

I assume they're either using USB headphones or some other case of having multiple audio output devices, like my desktop with onboard sound and a separate PCI sound card.

That does not apply to non 3.5mm headphones and even those are software driven now in many notebooks.

> If that really is the case you could use dmix and have audio played on both the headphone and speaker output. You would still have to mute the speakers when plugging in the headphones though.

You're stating that Pulseaudio isn't necessary because someone could do the same thing with a combination of dmix and manual intervention? Have you considered the possibility that someone might like the convenience of not needing to do manual intervention?

Huh? I never stated that Pulseaudio isn't necessary.

I just pointed out a possible solution/workaround with ALSA and dmix for redirecting the audio output to two devices/pcm outputs.

After years of using just ALSA and messing around with its config on different computers I am now using Pulseaudio too. Once it's running it's a lot easier to use and more flexible, especially when it comes to hot-plugging and switching between inputs and outputs.

PulseAudio features I have used in the past that I don't think ALSA has:

* playing audio from/to another Bluetooth device (with bluez)

* playing audio on a PulseAudio server running somewhere on the network

* transparent encoding of audio output as DTS (for surround support over SPDIF)

I also seem to remember plain ALSA having trouble with multiple applications playing sound at the same time, which is just pathetic.

I'm sure some of these could in theory be built on top of ALSA, but fact is that today's Linux distributions use PulseAudio, and for me it always worked well.

I'm not sure about ALSA's capabilities in this area, but one thing PulseAudio does well is moving playing audio streams between sound devices. (For example, moving it from my monitor's speakers to my USB headphones.) Being able to control mixers on a per-application basis is also quite nice.

How do I make my bluetooth headset (which supports both A2DP and Handset profile) work with ALSA so it switches to headset profile when mic is active, reverts to A2DP when it's not and switches back to laptop audio when BT is off?

How's the situation for hotplugging sound devices in ALSA nowadays? The top Google results for "alsa hotplug" all point to editing configuration files or udev rules or shell scripts.

On the flip side, if everything can be done by ALSA, and PA is seemingly objectively worse, for what reason are people building their software against PA? Why is it being included anywhere at all?

The power of defaults.

Why write for ALSA when the distro ships with PA, and so all of its configuration tools are PA-focused?

Also pulseaudio allows them to sorta support OSS and whatever else pulseaudio will output to for free.

Because many devs are on Linux distros, that include PulseAudio by default. Support for *BSD ports is often a bit weak for software like that.

Basically it's a RedHat conspiracy to make open-source programs not work on non-Linux.

I don't see how building your program against ALSA (Advanced Linux Sound Architecture) would make it more compatible with non-Linux OSs.

Maybe @lmm wishes that Redhat threw support behind OSS4? Is that supported under the *BSDs?

Except ALSA cannot do everything that PA does. ALSA is low-level Linux sound API that PA builds on. Read the post above, it explains the difference.

Basically, if you want multiple sounds playing at the same time (e.g. music + desktop notifications) and you don't have hardware mixer (many common sound chips don't and rely on Windows drivers/sound system to provide the functionality), you are out of luck (no, the ancient dmix plugin is not a solution!). Bluetooth audio (headsets) doesn't really work without PA.

Configuring apps to use different devices (music should go to speakers and video conferencing to a headset ...) is a pain without PA - most applications don't let you select the input/output devices.

And many other things. ALSA is good, but without PA the sound support on a modern Linux desktop would be stuck right in the late 90s. Is it necessary? Not strictly, but it is one heck of a convenience that most don't even realize they have.

Here is a good post from 2008 explaining many of the issues PulseAudio solves and addressing some of the old FUD:

http://0pointer.de/blog/projects/jeffrey-stedfast.html

Unfortunately, there are tons of people with strong opinions about both PA and systemd but very little actual knowledge about what these components do and what issues they address in a modern Linux/Unix system. But that doesn't prevent them from spreading BS FUD and conspiracies about this or that group trying to dominate the market or take over the competing Linux distros.

>no, the ancient dmix plugin is not a solution!

Given that that's exactly what it's for, why isn't it?

Reply on news.ycombinator.com