After Lennart posted his summary of Linux sound APIs, the debate heated up again between ALSA and OSS zealots. Both ALSA and OSS developers think their API is the definitive interface for sound support in Unix and like to bash each other, and tell how the other API sucks and how the others are spreading FUD.

This is not only a sterile debate, but it is completely irrelevant. Do you know why? Because neither of them is a suitable sound API.

Technical constraints, functional requirements and history make the “ideal” sound stack on Linux look like the following:

• a sound driver, consisting of a kernel module and if necessary a low-level library
• if configured so, a sound daemon which brings software mixing and network support – PulseAudio finally kicking out all crappy alternatives
• a high-level programming API for use by developers.

When you develop a multimedia application or a mixer controller, why would you care of the insanely complex ALSA library or to make ioctls somewhere in /dev when GStreamer and Phonon provide you with high-level functions that can do it in a snap? When you want to insert sounds in your game or application, why would you care of those bits when, with SDL_Mixer or libcanberra, a single line of code is enough to decode and play the sound?

If we want to see sound working properly under Linux, we need to keep the stack simple and to clearly separate the roles. In the end, this boils down to very simple things:

• Application developers must stop using ALSA and OSS. Both of them are completely unsuitable for the task, and it only serves the purpose of letting ALSA and OSS developers troll. Whichever application you are writing, there is one of the high-level frameworks – SDL, GStreamer, Phonon, libcanberra, KNotify, JACK – that is better.
• OSS and ALSA should stop trying to be application-level APIs. Instead of trolling about which API is better, they need to write drivers so that sound fucking works instead of asking users to use Windows to see their brand new computer output some sound.
• The plumbing layers (backends for the high-level APIs and PulseAudio) need excellent support for both ALSA and OSS. In the end, what matters is to have a driver for your sound card and to have it usable by all applications. Keeping the driver layer independent from the sound API is the only reliable way to keep things working over time. If someone else starts writing yet another driver framework, we will be able to make applications use it, instead of adding yet another ton of compatibility stacks.
• In the end, compatibility layers that cross layers in the stack must disappear. ALSA emulation for PulseAudio? OSS emulation with a LD_PRELOAD hack? Seriously, WTF? Applications should not have used them as a sound API, and we need to trash this crap eventually.

Please, guys, hold off a minute. You are developing drivers and you must be praised for that. Keep doing that well, and stop trying to invade applications. There are people who may not know how to develop a driver, but who obviously know better what a sound API should look like.