I was entirely happy with alsa and still don't know of any use-case I have that's better served by the more fragile, more resource-hungry PulseAudio. I assume it's useful to someone.

Spoken confidently like someone that never tried to play sound in two applications at once.

I keep seeing this argument in this thread and quite frankly I'm dumbfounded. Last time I've had this issue was more than a decade ago on FreeBSD and it was solved by tweaking my OSS config to enable multiple channels. I've never, ever had this issue with Alsa. And I'm not a fan of Alsa either, PA just managed to be even more opaque and less reliable in my experience.

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.

FreeBSD's OSS is not ALSA.

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.

Alsa has had dmix for quite some time. The thing was that until something like a decade ago it had to be manually enabled via a .asoundrc edit. These days Alsa will enable it automatically on any device known to not have a hardware mixer.

Maybe so, but I did try to fix it without resorting to a hardware sound card and couldn't at the time. IIRC the syntax of the ALSA configuration files was particularly arcane.

Not sure why that deserves downvoting.

Also spoken confidently like someone that never tried to play sound in two applications at once.

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?

Another "lovely" thing about PA is that will allow the loudest of the "apps" (groan) to ramp up the master control (do not recall the "feature" name right now).

Do wonder how much future hearing loss it has created by sudden spikes in volume...

You are talking about "flat-volumes", I also recommend disabling it. Even forgetting the issue you mentionned, it just makes volumes harder to handle and reason about.

I wonder if they would have ever implemented this "feature" if it wasn't the default (and only) behavior on Windows...

Oh! When all of the GUIs say sound is at max, but it's either really quiet or silent, and it turns out that it's because even though the PA volume is up, somehow ALSA (which PA ultimately uses on the backend) got muted. But this is a PA box, so you have no GUI tools to set the ALSA volume!

This has worked reliably in ALSA before it has worked reliably in PulseAudio (and, in fact, way before PulseAudio received any meaningful adoption, when Fedora enrolled everyone in PA's beta testing).

Well, maybe in the later days, but there was a long time when it didn't work well at all. I remember having to mess with the ALSA configuration to make it work. And then you also had apps which only supported OSS and getting them to work together with ALSA was an additional pain.

The reason for that was that while dmix was available for a long time, it was not enabled automatically on hardware without hardware mixing. More recent versions will silently (heh) enable it on hardware thats known to not have hardware mixing.

What later days? Software mixing worked fine in ALSA in 2004-2005, and OSS emulation had been working reliably way before that. The first PulseAudio release was in 2004, and it wasn't adopted by Fedora until way, way later.

dmix works just fine for "normal users" and has since the first time I used it (sometime in 2005 or so)

How did you ensure one app wasn't much louder than the other ?

I'm trying to think of a software audio source that doesn't have its own volume control and I'm failing.

Chrome, for example. Remember http://packet.city/ from a few days ago? All Chrome supports is mute or unmute.

Hm...

* 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.

Your proposed Alsa solution: Now all other apps with reasonable dynamic range, e.g., movies, are too quiet.

At the same time, all other apps are at a level that won't cause painful audio to hit your ears.

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.

Then you tell your movie player to just make it louder, discarding that beautiful dynamic range. If you're paying close enough attention to the movie to care about the loss of dynamic range, then you probably aren't doing something else that might make sound, so you won't mind turning the master volume up.

So how do you ensure that one tab wasn't much louder than the other?

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.

In my use, zero or one tabs is producing sound at any one time, so the distinction doesn't really matter to me.

And in most people's use, zero or one applications is producing sound at any one time, so the distinction doesn't really matter to them.

I haven't had a problem with that at all, so I'm not sure :)

I think the use cases you're describing are quite distinct from a "Linux on the desktop" user. The audio experience for this kind of user (myself included) has improved dramatically in the past few years.

I'm a desktop Linux user; I preferred the old way. I do get that most people like multiplexing (I don't; I want exactly one sound source at a given time), and I'll grant that has improved.

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.

> I don't; I want exactly one sound source at a given time

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.

I hate app feedback and notification sounds. I hate notifications in general; I prefer to poll for information I need on my schedule. This is also why I hate desktop environments and use a simple full screen window manager. One task at a time. Hell, lately I don't even bring up X every day if I don't need to. Tl;dr: I'm old.

Or wise, and you take control of your own attention.

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.

I'm with you regarding the value of multiplexing. I don't use it much, but it was really annoying back in the day when one program would block another program's sound.

> 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).

There are some framebuffer[1] consoles[2] that work really well when you do need to mux outside of X.

[1] https://www.freedesktop.org/wiki/Software/kmscon/

[2] https://code.google.com/archive/p/fbterm/

There's nothing quite as jarring as having a pleasant piece of music turned up, only to have some off-key and out-of-time bell ding because an email arrived. Want to let me know there's a new email? Put a little envelope on the task bar so I can see it. Don't invade my music!

> I still have difficulty believing that people actually use bluetooth for audio

So you don't believe that somebody would like to be able to use wireless headphones?

Exactly. Why would you trade something that doesn't require power, has the most reliable, secure, and lossless transmission channel known, and is "configured" by plugging in hardware for something that requires power, has a less reliable transmission channel that can be easily snooped or forged, has to be configured in software? I literally don't understand why anyone would ever choose the latter.

I want to own exactly one wireless headset/microphone so that I can get up from my computer without having to excuse myself from voice chat.

Like a laptop or smartphone has over a stationary computer, wireless headsets have a freedom-of-movement benefit over wired.

I don't: wireless headphones seem strictly worse in every way than wired. They require batteries and charging; they introduce lag; they are expensive; they are easier to lose; they don't have a convenient cable to hang on to.

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.

> seem strictly worse in every way than wired.

The same as wifi, right? Strictly worse in every way. Except for the not needing wires way.

Although...different use-cases there, for me. I've got a dozen audio sources, either connected to speakers (the TVs) or within a couple feet of me when I'm using it (phone, media player, tablet, laptop). So, a bunch of sources, a couple of which I might be listening to at once. All either in short enough distance for cords, or loud enough that it's moot.

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.

Wifi has encryption. Bluetooth means I'm broadcasting my audio stream to anybody who feels like snooping on me.

Not quite.

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.

As a matter of fact, my desktop & my laptop are both wired, and I hate how flaky WiFi is on my phone & tablet. Just moving to different rooms in my (small house) does horrible things to my network connexion speed — but Ethernet keeps on chugging along.

Or want to play music from my laptop to my stereo speakers?

> allegedly because it was needed for bluetooth

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.

Well, it improved years ago (like, ten!) and I haven't had to worry about it in recent years.

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.

A massive sad part of all this is that so much of what is going on in Linux DE land right now seems to be driven by a pipe dream called multiseat. Or effectively using software to turn a Linux desktop install into a desktop mainframe.

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.

Serious question: I remember claims that poorer countries basically switched to smartphones instead of PCs and phones are supposed surprisingly ubiquitous there. Can anybody confirm that?

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.

It's certainly true in urban India (and becoming more true in rural India). And this has the added bonus of bringing people into the banking system because you can store, send, and withdraw cash from your mobile account (this started in sub-saharan Africa but is becoming more of a thing in rural India too).

And what happened when two processes wrote to that file? And what if they where each in a different sample rate? ....

Well, sound mixing and resampling are a thing. Other operating systems do that where it belongs: in the kernel. OSS gets it right, for example.