
PulseAudio has been removed from dports - wolfy
http://lists.dragonflybsd.org/pipermail/users/2016-August/313010.html
======
justinsaccount
2000: Audio on linux sucks. If you are lucky you can have two applications
generating sound at the same time. You can't hotplug audio devices. You can't
have per application volume. You can't move audio streams to different output
devices.

2016: Pulseaudio sucks because.. reasons.

~~~
mmastrac
It's an easy target. It sucks far less all the alternatives, but it's an easy
punching bag for people who want something to hate.

I lived through the days of horrible sound support on Linux - I think it was
my main desktop until my first Mac around ~2007. Playing video or games was a
crapshoot. Hot-plugging audio wasn't even in the realm of possibility.

------
klodolph
I have a love-hate relationship with PulseAudio, and it seems others do too.

It makes sense to have some user-space audio layer. Software mixing, sample
rate conversion, and a few other things just make sense in user space, and we
can expose only bona fide hardware capabilities through the device interface.
Of course, most desktop audio chipsets have hardware mixing, which means that
most people think that you can just use OSS (or ALSA on Linux), and it will
work. It just doesn't work on everybody's hardware.

In short, there's a hardware jungle out there and software layers like
PulseAudio smooth over the differences. It's a shame that it doesn't always
work well, and most people think PulseAudio is the source of the problem
because most people have hardware mixers.

By comparison, if you just use OSS (or ALSA on Linux) on my computer you might
see that incredibly basic features _like volume control or the ability to play
audio from multple apps_ don't even work without PulseAudio.

------
qwertyuiop924
PA is pretty painful, but credit where it's due: Now that linux's OSS support
is pretty much dead and buried, it's pretty much the only way to do cross-
platform sound on the unixes. Even if it is a baroque, overly complex mess (it
is), it has helped to increase portability across systems.

Not that it matters, as Wayland and systemd slowly eradicate all cross-
compatability in software complex enough to care.

Which is kind of ironic, when you think about it...

------
AceJohnny2
Understaffed BSD fork can't maintain notoriously complicated and finicky user-
space audio daemon, decides to drop it instead. News at 11.

Honestly, I'm surprised DfBSD even supported PulseAudio (or vice-versa) in the
first place.

~~~
mveety
If it works on FreeBSD it will probably work on Dfly. They're still pretty
close in terms of userland, and I don't know this for certain but they
probably take many FreeBSD changes and vice-versa.

------
dTal
Vast amount of revisionism in this thread.

Lots of comments saying ALSA doesn't do mixing. This is false. ALSA has always
supported mixing through dmix, and it's enabled by default.

Lots of comments saying ALSA doesn't do hotplugging. This is also false -
hotplugging works like any other hardware on Linux. Plug it in and it shows
up. To configure that card as the default requires changing a configuration
file. You can make this happen automatically with udev.

Lots of comments saying ALSA doesn't work with bluetooth headsets. Google
"bluez-alsa" folks. FFS.

Now, that's not to say that all of this worked seamlessly. Configuring
everything through /etc/asound.rc or .asoundrc was a pain, in large part
because there were no GUI tools to do so. And because applications read
.asoundrc on startup, there was no way of _switching_ a playing stream to a
different card, live. THAT is the use case that a userspace daemon solves.

The upsetting thing is we already had two userspace daemons, aRts and ESD [KDE
and GNOME respectively], that more or less worked fine. Instead we suffered
with years of broken audio.

------
frign
Look at sndio if you want to see how sound should be done. Excusing the
horrible mess pulseaudio is with the horrible state of Linux Audio doesn't cut
it, when OpenBSD has been offering a superior and simpler alternative for
years!

It doesn't reinvent the wheel and for anything more complex you can always use
JACK, like if you really want to go low-latency.

~~~
pyre
> Excusing the horrible mess pulseaudio is with the horrible state of Linux
> Audio doesn't cut it,

The problem is that most people complaining about Pulseaudio don't offer
realistic alternatives. Saying Pulseaudio sucks and that everyone should use
ALSA is a joke. Pulseaudio does a plethora of things that ALSA does not
handle. Not to mention that ALSA is a low-level system, and PA actually sits
_on top of_ ALSA.

In all of the vitriol that people spew about Pulseaudio, this is the first
time that I've seen anyone point to sndio. I think that says something about
the "pulseaudio complainers" crowd.

That said does sndio provide the following features:

\- Support for bluetooth audio devices

\- Support for streaming audio over a network.

\- Support for user-land mixing of audio sources (i.e. don't need root).

\- Mixing of multiple audio streams at the same time (e.g. Can your system
play an alert sound without interrupting your music?)

\- Per application volume settings

\- Per application input/output source settings

~~~
tobik
I realize I'm replying to a 2 weeks old comment, so nobody will read this
ever, but from your list sndio supports: streaming audio over a network, user-
land mixing of audio sources, mixing of multiple audio streams at the same
time, and per application volume settings.

> Per application input/output source settings

No, but the input/output device is selectable per application via the
AUDIODEVICE environment variable.

> bluetooth audio devices

OpenBSD has no bluetooth support, so no. I'm also wondering why the kernel
wouldn't create audio devices from these that the userland daemon can then
just transparently use? Does an audio daemon need special support for
bluetooth audio devices?

The sndio daemon has more features. Give the man page a read if you're
interested: [http://man.openbsd.org/OpenBSD-
current/man8/sndiod.8](http://man.openbsd.org/OpenBSD-current/man8/sndiod.8)

------
betaby
Honest question, why would one need another layer of PA in linux if alsa does
mixing just fine. I've heard PA is useful for bluetooth devices. Any reason
why it's needed beside that?

------
AstralStorm
Removal is the best fix, always. Who needs features anyway.

~~~
na85
>Who needs features anyway.

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

~~~
abstractbeliefs
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?

~~~
janoc
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](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.

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

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

