Removal is the best fix, always. Who needs features anyway.
Pulseaudio did not work on DragonflyBSD. At all. Hence the removal. A feature that doesn't work isn't really a feature, is it?
PulseAudio has been removed from dports
11–20 of 55 posts
Re: PulseAudio has been removed from dports
#12Removal is the best fix, always. Who needs features anyway.
This is a dumb comment and akin to predicting the iphone would fail because it doesn't have flash support. Pulseaudio is a very finicky troublesome bit of open source software. The alternative (ALSA) is much more friendly to work with. Any seasoned sysadmin probably welcomes the death of Pulseaudio.
I wouldn't really consider ALSA as an alternative to PA, considering that PA generally sits on top of ALSA instead of replacing it. aRts and ESD of the olden days would be more comparable.
Re: PulseAudio has been removed from dports
#13Removal is the best fix, always. Who needs features anyway.
>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.
Re: PulseAudio has been removed from dports
#14Removal is the best fix, always. Who needs features anyway.
>Who needs features anyway. Can you name a single feature or use case addressed by PulseAudio that isn't addressed by ALSA?
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.
Re: PulseAudio has been removed from dports
#15Removal is the best fix, always. Who needs features anyway.
>Who needs features anyway. Can you name a single feature or use case addressed by PulseAudio that isn't addressed by ALSA?
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.
Re: PulseAudio has been removed from dports
#16Earlier quoted context omitted.
This is a dumb comment and akin to predicting the iphone would fail because it doesn't have flash support. Pulseaudio is a very finicky troublesome bit of open source software. The alternative (ALSA) is much more friendly to work with. Any seasoned sysadmin probably welcomes the death of Pulseaudio.
Let's be fair: PulseAudio is the way to go if you have to have a partitioned audio system because you are using a multiheaded multiuser system where each seat has a monitor and keyboard and mouse and mic and speakers, and each user needs to be able to control their own volume mixing without root privileges. For every other case I've seen, ALSA is better and causes fewer problems.
I have already encountered the need for multiheaded system. I wanted to run a second X server on my third screen in order to have a separate mouse. I have not found any website explaining this kind of setup. I have never succeeded: the mouses were active on both X servers.
Re: PulseAudio has been removed from dports
#17Removal is the best fix, always. Who needs features anyway.
This is a dumb comment and akin to predicting the iphone would fail because it doesn't have flash support. Pulseaudio is a very finicky troublesome bit of open source software. The alternative (ALSA) is much more friendly to work with. Any seasoned sysadmin probably welcomes the death of Pulseaudio.
ALSA is not an alternative to Pulseaudio.
If your audio chipset doesn't have a hardware mixer, and about of half of laptop chipsets don't, then you can't play more than one stream at a time. If you have an array microphone, the only way it'll work at all is with Pulseaudio. If you want Bluetooth audio, only Pulseaudio bothers to support it.
Pulseaudio uses ALSA anyway (and on DFBSD it uses OSS instead); it's not a replacement, it is the only unix sound server other than Apple's(and maybe OpenBSD's) which actually works. ALSA is an audio device driver ABI; it can only expose what your chipset supports in hardware.
The problem of Pulseaudio spinning, at least when it used to happen on Linux, is due to issues in the individual audio device drivers. The reason this is a big problem is that Pulseaudio needs to run at a low `nice` value in the scheduler, or you will get buffer underruns (which sound like pops and clicks). Unfortunately this means that if Pulseaudio goes into a hot loop, it will consume all of the available CPU resources until the loop breaks. This problem can be mitigated by running pulseaudio with a control group to limit CPU time (as is done with systemd on many Linux distros). Unfortunately, DragonFlyBSD doesn't have the same thing configured, assuming their kernel supports it, so you get 100% CPU spinning.
Furthermore, DragonFlyBSD doesn't have ALSA; they have OSS.
Re: PulseAudio has been removed from dports
#18PA 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...
Re: PulseAudio has been removed from dports
#19[deleted]
Re: PulseAudio has been removed from dports
#20Earlier quoted context omitted.
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?
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.