> including the raw Linux ALSA sound API, which typically allows only one application to access the sound card.
If the raw in that sentence is not meant as a special qualifier and this is meant as a statement about ALSA in general, this is wrong. I recently read up on this to confirm my memory was right when reading a similar statement. In fact, ALSA had just a very short period where typically only one application accessed the sound card. After that, dmix was enabled by default. Supporting multiple applications was actually the big advantage of ALSA compared to OSS, which at the time really did support only one application per soundcard (without hardware mixing, which broke away at that time). I'm not sure why this seems to be remembered so wrongly?
> Speaking of transitions, Fedora 8's own switch to PulseAudio in late 2007 was not a smooth one. Longtime Linux users still remember having the daemon branded as the software that will break your audio.
This wasn't just a Fedora problem. Ubuntu when making the switch also broke Audio on countless of systems. I was active as supporter in a Ubuntu support forum at that time and we got flooded with help requests. My very own system did not work with Pulseaudio when I tried to switch, that was years later. I still use only ALSA because of that experience. At that time Pulseaudio was garbage, it should never have been used then. It only got acceptable later - but still has bugs and issues.
That said, PipeWire has a better vibe than Pulseaudio did. It intends to replace a system that never worked flawlessly, seems to focus on compatibility, and the apparent endorsement from the JACK-developers also does not hurt. User reports I have seen so far have been positive, though I'm not deep into support forums anymore. Maybe this can at least replace Pulseaudio, that would be a win. I'm cautiously optimistic about this one.
The ALSA interface can actually refer to two different things:
1. The ALSA kernel interface
2. The interface provided by libasound2
The former is basically the device files living in /dev/snd, this interface is hardware dependent and whether you can or cannot send multiple streams to the sound card all depends on the actual underlying hardware and driver support.
The later is actually a shared library that when linked into your application exposes "virtual" devices (such as `default`, or `plughw:0` ...), these devices are defined through plugins. The actual configuration of these virtual devices is defined in `/etc/asound.conf` and `~/.asoundrc`. This is typically where dmix is defined/used. Which means that if you have any application that does not use libasound2 or uses a different libasound2 version, you are in trouble.
p.s. Pulseaudio implements alsa API compatibility by exporting an alsa device plugin to reroute audio from all applications making use of libasound2 (except itself).
I've found https://www.volkerschatz.com/noise/alsa.html to be a good overview of ALSA's architecture (though many of the things mentioned, like ogg123, are no longer in common use).
> In fact, ALSA had just a very short period where typically only one application accessed the sound card.
For some definition of 'short period'. Software mixing via dmix worked for me, but at the time I've heard for years that dmix was broken for many other people. Not sure whether things are better nowadays.
The breakage seems to be caused by hardware bugs. Various authors had the stance that they refuse, on principle, to work around hardware bugs. I guess I understand the technical purism, but as a user that attitude was unhelpful: there was no way to get sound working other than to ditch your laptop, and hope that the next one doesn't have hardware bugs. In practice, it seems a large number of hardware had bugs. Are things better nowadays?
I had a sound card that would not work with OSS in 2002ish, so I guess define "default choice." Even though it was technically disabled by default, I had to enable it to get sound working.
> My very own system did not work with Pulseaudio when I tried to switch, that was years later. I still use only ALSA because of that experience. At that time Pulseaudio was garbage, it should never have been used then. It only got acceptable later - but still has bugs and issues
In the interest of balance, PulseAudio was a huge improvement for me.
I remember playing SuperTux on my laptop. After the switch to PulseAudio, the sound was flawless. Before that, on ALSA, the audio was dominated by continuous 'popping' noises—as if buffers were underrunning.
> the apparent endorsement from the JACK-developers also does not hurt.
Indeed, it seems a better UX to only require one sound daemon, instead of having to switch for pro work.
My understanding back in the mid 2000s when I first got into Linux was that OSS only let you play one audio stream at once, and the whole point of ALSA was that it let multiple applications access the sound card.
I guess I could be remembering that wrong, but I know I was listening to multiple audio streams long before PulseAudio came onto the scene.
OSS in non-free versions supported multiple sources. Linux sound guys decided that instead of fixing the free OSS they would write ALSA. They never really worked out all the bugs around mixing before pulseaudio took over.
It's more than 20 years later and still I don't understand these complaints. ALSA was designed to have a broader API than OSS, and it has supported OSS emulation for quite some time. What else could have been done when OSS went non-free?
I mean Linux, it does the same but reversed: the kernel implements the ALSA API, and libaoss is provided for backwards compatibility in userspace with OSS. What else should they have done? The ALSA API is not the same as OSS and has a different set of features.
It sounds like Linux and BSD both have an implementation for both APIs, only implemented in different ways? If so, I don't much see where the problem is with this solution.
They don’t. And the problem is that replacing a popular API with a proprietary one, like ALSA, creates a lot of work for everyone, for no reason other than NIH.
PulseAudio and PipeWire embody the correct approach. The problem with OSS is, if you're using anything resembling modern audio formats, it risks introducing floating-point code into the kernel, which is a hard "no" in mainline Linux. So if you need software mixing, it should be done in a user-space daemon that has exclusive access to the sound card.
Jop, definitely. I still remember this clearly because I was into gaming. And while I could play some games with wine, Counter-Strike iirc, my friends used Teamspeak. Teamspeak had a proprietary linux version, but it used OSS. Before `aoss` became a thing (or maybe just known to me) there was no way of having teamspeak on and ingame sound, and teamspeak needed to be started before the game.
Only using alsa fixed this, mumble I think then became a good alternative for a short while.
I don't remember this at all, but this might explain that. Or maybe a distribution like debian stable shipped with an outdated ALSA version, taken from the short period between release and dmix. Or just disabled dmix. Would love if someone remembered specifics.
I kinda assumed people mix up Alsa and OSS or don't remember anymore what actually did and what did not work before Pulseaudio was introduced.
In the early 00's (before PulseAudio), my desktop had an old SoundBlaster Live PCI card that was pretty common around the turn of the millennium. ALSA dmix Just Worked with that one.
Any other hardware I encountered required some kind of software mixing, IIRC. Not that my experience was extensive, but I got the impression that hardware or driver support for dmix wasn't that common.
Hardware mixing was killed, because it turned out that it is more efficient to mix several streams with CPU and move just a single one via the bus. It was also more flexible and without weird limits - for example, GUS could mix 14 streams at 44,1 kHz, and if you went above (up to 32), the frequency of each stream went down.
That's why PulseAudio and PipeWire run as real-time. Or they should.
Back when Pulse was new and I was running Gentoo I used to help other Gentoo users get their real-time settings correct. I believe we used rtprio in limits.conf. I don't recall when RTKit became a thing.
If your sound daemon is running as real-time and still missing deadlines then there's something wrong with your system hardware. Or I suppose, the sound source feeding the pulseaudio daemon is not getting enough CPU time.
I think they indeed should run at a (low) real-time priority, but only if they are limited to a fraction of total available CPU power, with say cgroups or similar.
Otherwise they can easily lock up the system, and that should not be the default configuration.
> My very own system did not work with Pulseaudio when I tried to switch, that was years later. I still use only ALSA because of that experience. At that time Pulseaudio was garbage, it should never have been used then. It only got acceptable later - but still has bugs and issues.
I remember the transition to PulseAudio. Initially, most things were broken, and we still had some applications that worked only with OSS so the whole audio suite in Linux was a mess. I remember that I already switched from Fedora (very broken)/Ubuntu (slightly less broken) to Arch Linux, and for sometime I kept using ALSA too.
Eventually, between switching Desktop Environments (I think Gnome already used PulseAudio by default them, while KDE was optional but also recommended(?) PA), I decided to try PulseAudio and was surprised how much better the situation was afterwards (also, OSS eventually died completely in Linux systems, so I stopped using OSS emulation afterwards).
With the time it was getting better and better until PulseAudio just worked. And getting audio output nowadays is much more complex (Bluetooth, HDMI Audio, network streaming, etc). So yeah, while I understand why PipeWire exists (and I am planning a migration after the next NixOS release that will bring multiple PipeWire changes), I am still gladly that PulseAudio was created.
I’m using pipewire in NixOS unstable and it’s working very well. I know they are working in integrating new pipewire configuration with Nix configuration.
I am just waiting the release of the next NixOS stable version, since the integration in the current stable version (20.09) is still lacking some important features.
You know how some people say C thinks every computer is just a fancier PDP-11 ?
OSS thinks every computer's audio playback devices are just fancier CT Soundblasters.
If you've got a typical generic PC with Intel HDA or AC'97 (or indeed, an actual PCI Soundblaster) and what you'd like to have happen is that you can run your VoIP software, and listen to MP3s and also have new mails go "bing!" then "all the world is a Soundblaster 16" is close enough.
But if you've got a USB headset you plug in to take those VoIP calls, and a pair of bluetooth earbuds for listening to music, but you want new mail noises on speakers - you will start to struggle. These things aren't enough like a Soundblaster, neither in terms of how they're actually working nor in terms of how you expect to use them.
PulseAudio does a much better job there, because it's the right shape, and now it seems PipeWire is a better shape for modern environments where it's not necessarily OK for the software that plays smooth jazz from the Internet to be technically capable of listening in on your video conference calls.
PulseAudio sits above the level of OSS/ALSA to do that magic. Layers are often a good things when it separates concerns and makes the whole easier to handle.
Another point against dmix: I would be surprised if it worked with sandboxes like Flatpak. That may be another reason why major desktop-oriented distros like Fedora Workstation haven't embraced it.
That's a very old wiki page with decades old workaround for decade old issues. I'm not saying you are wrong, but if you take this impression solely from that wiki page you are likely mislead. Afaik this always works and did for many years - but I might be wrong and always only lucky with all the systems where I tested it?
If the raw in that sentence is not meant as a special qualifier and this is meant as a statement about ALSA in general, this is wrong. I recently read up on this to confirm my memory was right when reading a similar statement. In fact, ALSA had just a very short period where typically only one application accessed the sound card. After that, dmix was enabled by default. Supporting multiple applications was actually the big advantage of ALSA compared to OSS, which at the time really did support only one application per soundcard (without hardware mixing, which broke away at that time). I'm not sure why this seems to be remembered so wrongly?
> Speaking of transitions, Fedora 8's own switch to PulseAudio in late 2007 was not a smooth one. Longtime Linux users still remember having the daemon branded as the software that will break your audio.
This wasn't just a Fedora problem. Ubuntu when making the switch also broke Audio on countless of systems. I was active as supporter in a Ubuntu support forum at that time and we got flooded with help requests. My very own system did not work with Pulseaudio when I tried to switch, that was years later. I still use only ALSA because of that experience. At that time Pulseaudio was garbage, it should never have been used then. It only got acceptable later - but still has bugs and issues.
That said, PipeWire has a better vibe than Pulseaudio did. It intends to replace a system that never worked flawlessly, seems to focus on compatibility, and the apparent endorsement from the JACK-developers also does not hurt. User reports I have seen so far have been positive, though I'm not deep into support forums anymore. Maybe this can at least replace Pulseaudio, that would be a win. I'm cautiously optimistic about this one.