PulseAudio has been removed from dports • Hacker News Board

Re: PulseAudio has been removed from dports

#51

Post by dTal » Mon, Aug 22, 2016, 7:45 PM UTC

janoc wrote: post #31

abstractbeliefs wrote: post #5

Earlier 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?

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 anci…

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

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

Re: PulseAudio has been removed from dports

#52

Post by dTal » Mon, Aug 22, 2016, 8:24 PM UTC

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.

Re: PulseAudio has been removed from dports

#53

Post by pyre » Mon, Aug 22, 2016, 8:52 PM UTC

ne0phyte wrote: post #24

Symmetry wrote: post #13

Earlier quoted context omitted.

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…

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.

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

Re: PulseAudio has been removed from dports

#54

Post by ne0phyte » Mon, Aug 22, 2016, 9:02 PM UTC

pyre wrote: post #53

ne0phyte wrote: post #24

Earlier quoted context omitted.

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.

> 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 need…

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.

Re: PulseAudio has been removed from dports

#55

Post by tobik » Sun, Sep 04, 2016, 6:06 PM UTC

pyre wrote: post #41

frign wrote: post #36

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.

> 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…

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