DragonFlyBSD Decides To Drop PulseAudio

[drSeehas]

Pulse has been working perfectly fine for me for a number of years, even (*gasp*) made a number of use cases significantly easier.

You all use DragonflyBSD?

[starshipeleven]

A better headline would be: "PulseAudio is unmaintained and broken for many *BSD platforms". The same problems you can find on NetBSD.

Fixed it for you. You forgot a *BSD in there.

[beast]

Fixed it for you. You forgot a *BSD in there.

Do you really think outside of Linux PulseAudio is maintained? lol.

[starshipeleven]

Unfortunately, this is disabled by default in favour of flat volumes

You sure? I thought they were two different things.

Even more unfortunately, sound hardware generally already had a separate headphone volume control that was available in ALSA but overridden by PulseAudio.

Not overridden in any way, it's not used but it is still there and fine. Sometimes for unknown reasons ALSA likes to play tricks and pulls down one of its hardware volumes (either the right or left, or disables the output entirely), only way to fix that is with alsamixer (or editing ALSA configs).

To add an extra cherry to the shit sandwich, some pre-flat volumes apps like to set their application volume to 100% at startup.

I'm hard-pressed to find one. Even total shit apps like Skype added support for that like in 2009.
That might explain why by default the flat volumes are on.

[markg85]

In the past, i hated pulseaudio. It wasn't anywhere near good software, caused 100% cpu spikes and just didn't work well at all.
The principle was fine and hard to get via other means (mostly dynamic volume mixing; that could be done with dmix or oss or a few others that i probably don't know).

These days (specially since v8.0) pulseaudio really works well for me! The issues that i still have with sound aren't caused by pulseaudio anymore, but are caused by applications doing what they "think" is right which in turn breaks things.

1. like dynamic input switching when you plug in a usb headset. It works if you load the module "module-switch-on-connect" (isn't loaded by default), but on Plasma5 that does not work since there is a sound manager configuration part in System settings which apparently requires "module-device-manager" to be loaded. The two modules conflict with each other resulting in module-switch-on-connect to just not work. Plasma knows this, but they deem it "valuable" to keep it as it is. I disagree.

2. Some applications use their own volume mixing and start at 100% output by default. I see this as a remnant of the old ALSA days, but it is apparently quite strong still. MPV for instance has re-introduced this - in my opinion bug - in version 0.18.1. There are a couple of issues about it: https://github.com/mpv-player/mpv/issues/3362 but the maintainer is very unwilling to even look at it. There also is a workaround for it so that it works with dynamic volumes again (and restored it at startup), but that is not the default! So by default you will now get a 100% volume out of mpv and consider it a bug or even crappy software. That's not the case, you just have to do some work to get it working properly.

It are the above issues (multiplied by the number of apps that don't do sound properly) that cause annoyances and frustration for people that don't know how to configure it and blame PulseAudio for it. I'm most certainly not defending lennart poettering here, but i am about being fair to point out where issues are. These days they are quite simply unlikely to be in PulseAudio and much more likely to be caused by either the application itself or the distribution screwing stuff up.

The issues mentioned above are probably only issues for you if you're on a "configure everything yourself" distribution like Arch, Gentoo and a whole range of others. They are probably non existent (or rare) on user friendly distributions like Suse, Fedora and Ubuntu.

[starshipeleven]

Do you really think outside of Linux PulseAudio is maintained? lol.

No, I just made sure you weren't claiming PA isn't unmaintained on Linux.

"many platforms" includes Linux too, you know.

And I'm already ignoring the fact that PA is developed for linux, not "unmantained outside Linux" like you say, there is a slight difference in meaning but it matters.

Whoever wants to run it on other OSes must port it and maintain it, any failure to do so is squarely on the porting team.

[bug77]

Not overridden in any way, it's not used but it is still there and fine. Sometimes for unknown reasons ALSA likes to play tricks and pulls down one of its hardware volumes (either the right or left, or disables the output entirely), only way to fix that is with alsamixer (or editing ALSA configs).

Ha, ha. Been there, done that.
Initially KDE+Solid+PA=royal PITA, but for quite some time PA just works (I don't do fancy stuff on my desktop), so I just leave it alone.
I haven't followed ALSA in ages, but can it do per source independent volume? Cause I don't think I've seen that in alsamixergui.

[starshipeleven]

Ha, ha. Been there, done that.
Initially KDE+Solid+PA=royal PITA, but for quite some time PA just works (I don't do fancy stuff on my desktop), so I just leave it alone.
I haven't followed ALSA in ages, but can it do per source independent volume? Cause I don't think I've seen that in alsamixergui.

No, I'm talking of per-jack volume or enable/disable or L-R balance (works for both input and output connectors). It always had that afaik.

[caligula]

PulseAudio stole the show. At first I hated it, because my PCI soundcard wouldn't work, but they eventually fixed the bug and now I have no complaints -- sound "just works." (at least, well enough for typical desktop stuff)

So did you measure how the latency changed, is the buffering any different? It might just work if you're just playing stuff from youtube or mpv, but those requirements aren't that high. Heck, I have 2000 to 4000 ms latency with Airplay on my iPad connected to Shairport and it works just fine, according to quite many folks. Especially those who used the system. Of course the latency makes stuff like playing a game with sounds coming from external speakers just impossible due to the 2-4 second delay, but Spotify, Youtube and those all "work". Due to these limitations, I can't even imagine using it for any "demanding" purpose like karaoke. People in general are quite tolerant when it comes to audio latency. If you look at Linux menuconfig, they actually recommend a HUGE buffer for Pulseaudio users.. I wonder why if it's so great. Why doesn't JACK need multiple second buffers but PA needs them. I wonder why..

[ssokolow]

2. Some applications use their own volume mixing and start at 100% output by default. I see this as a remnant of the old ALSA days, but it is apparently quite strong still. MPV for instance has re-introduced this - in my opinion bug - in version 0.18.1. There are a couple of issues about it: https://github.com/mpv-player/mpv/issues/3362 but the maintainer is very unwilling to even look at it. There also is a workaround for it so that it works with dynamic volumes again (and restored it at startup), but that is not the default! So by default you will now get a 100% volume out of mpv and consider it a bug or even crappy software. That's not the case, you just have to do some work to get it working properly.

This makes me wonder if maybe we need PA to have an option to only allow "specially privileged" clients (ie. mixers) to change application volume settings, similar to the Wayland "apps can't be trusted" design philosophy.