Once upon a time, sound cards were files in the /dev tree. To play sound, you wrote pcm data to the file representing a sink. To record, you read pcm data from a file representing a source. Things were better then. I'm sure there are people with use cases that have required the four (and counting!) solutions crufted on since then, but I've never been one of them, and it irks me that the interfaces get more and more complex and brittle with each iteration.
Now, it's just anecdotic evidence of course but basic audio mixing is not exactly rocket science, you shouldn't need something as convoluted as PulseAudio to get it right. I mean, what the hell: https://gavv.github.io/blog/pulseaudio-under-the-hood/diagra...
Some power users might need these additional features, I don't. I wouldn't mind having all of that if the basics just worked reliably but they don't.
These days disabling PA is my go-to first step while troubleshooting audio issues on linux and more often than not I don't have to go to step #2.
ALSA refused to do mixing in software for some time. Maybe it still doesn't do it, I don't know. So if you had a hardware sound card that would do mixing, you could play multiple channels with ALSA, but if you didn't, you were SOL.
Not sure why that deserves downvoting.
This has worked well in ALSA for years now. Now, ALSA won't let you set the volume of each application separately, but most applications have their own volume control for that anyway.
And you'll never have to deal with the application's volume Pulse's volume for that source disagreeing, and scratching your head as to why even though you set the volume to max, it isn't getting very loud. To be fair, maybe this has been entirely solved; the last time I used Pulse was ~5 years ago[0], so I might be a bit out of date. But not more out-of-date than the claim that ALSA can't play sound in two applications at once!
[0]: I don't have anything against Pulse, I just don't see the point in installing it. What does adding it to my stack get me?
Do wonder how much future hearing loss it has created by sudden spikes in volume...
I wonder if they would have ever implemented this "feature" if it wasn't the default (and only) behavior on Windows...
* default Alsa setup: set master to level that seems comfortable-- i.e., "to taste"
vs.
* default Pulse setup: set Chrome's app level to taste
Bug: packet.city plays an annoying sound with a perceived loudness that the user did not predict.
* Alsa solution: lower the master volume to a level that doesn't result in painful output from packet.city, and adjust all other apps accordingly
vs.
* Pulse: lower Chrome app audio, but leave yourself open to similarly unpredictable painful events from other apps
It seems in this case that the limitations of Alsa actually force the user to do the safe thing wrt perceived loudness.
If you trust VLC and you trust the video file you're watching, then turn the master audio back up during the loud "Universal Pictures" intro or whatever is an equivalent introductory sound at the beginning of the movie you're about to watch.
On my chromebook, there are two volume buttons and one mute button that are by far the most convenient way to adjust (master) audio for such a situation. So you turn down for random browsing and turn up for watching movies or whatever.
Btw-- those are almost certainly the controls someone would use to turn down or mute the sound of that horrible website audio listed above. In such a case the fact that pulse can give you an app volume for Chrome doesn't help anything-- for example, the user who adjusted Pulse app volume down to avoid pain will need to adjust it back up when watching a movie on Youtube for the same reason you mentioned. But they can't adjust the app volume with the keyboard controls. So to make use of that feature forces a more complicated UI that takes longer to use.
In this case, it doesn't make much sense to treat the browser as a single application, but each site as one (does Chrome export each tab as a separate source to PA? IDK, I haven't checked). And, I can't think of a single thing that I actually want producing sound (and don't mind just muting) from my web browser that doesn't have its own volume control.
I banged my head against my desk for a couple of days when Slackware switched to Pulse with 14.2, allegedly because it was needed for bluetooth. I still have difficulty believing that people actually use bluetooth for audio, but apparently some people love it.
Really? So you want all app feedback to cease if you're playing music? No IM or new email notifications? That just seems like a pain to me.
Multiplexing can be handy if you like gaming, and having music from another application at the same time.
Also sometimes it's useful to have a reference manual in one side of the screen and your text editor in the other, or a PDF viewer on one side and a LaTeX editor in the other.
> Also sometimes it's useful to have a reference manual in one side of the screen and your text editor in the other, or a PDF viewer on one side and a LaTeX editor in the other.
True. An emacs which supported the framebuffer could do this (but GNU emacs currently only supports vt100, X, macOS & Windows, IIRC).
So you don't believe that somebody would like to be able to use wireless headphones?
I am completely and totally flabbergasted by their popularity. It's as though millions of people were turning their noses up at fine, free homemade French food and paying for McDonald's instead.
The same as wifi, right? Strictly worse in every way. Except for the not needing wires way.
Wifi: The internet comes from one (inconvenient) place in the home that I can't choose. I've got a couple of powerline ethernet adapters, but I've also got a lot of devices that handle wifi, but not ethernet. The choice is between using wifi or skipping the network connection. It's great as a last- (or only)-resort connection option, and it's usually sufficient, but then my uses for it are usually pretty tame anyhow.
Bluetooth was originally encrypted, but gained the option of non-encrypted channels with version 1.1.
On top of that Bluetooth use frequency hopping.
Until recently there was no real hardware for scanning/sniffing Bluetooth traffic, at least not anything easily available compared to a wifi card in promiscuous mode.
The bluetooth stack dropped support for ALSA with Bluez 5.0. About a year ago, dev started on a "bluez-alsa" or BlueALSA package the re-integrates an ALSA backend. I've used it briefly; it seems to work as advertised.
I think that Bluez 5.0 came out about the time that Slackware 14.0 did, so it makes some sense that versions before 14.2 would've provided Bluez 4.x for the bluetooth stack.
I still remember buying a hardware sound card (soundblaster emu10k) to enable ALSA to mix multiple sources (game audio + teamspeak or whatever voice chat people used back then) back in the early 2000s.
This by attaching a bunch of peripherals and use software to assign them to groups that effectively form the equivalent of a graphical terminal.
All this supposedly in the hopes of introducing affordable computing to schools in the developing world. But said schools have already tested and discarded this idea, so why the DEs keep pushing it is a mystery.
Seats never made much sense to me and if the smartphone story has any truth to it, then I do not see any valid use case for that idea these days.