Sean's Technological Journeys

I have a dream that my favorite audio applications will one day coexist in a configuration where they will not be judged by their choice of audio API, but by the usefulness of their functionality.

– Adapted from Martin Luther King’s “I Have a Dream” speech

This is a multi-page article; don’t miss the “Read More” after the teaser, and the page turner at the bottom of each page!

Follow up:

For years I have been musing on whether it is possible to create a so called “Universal Sound Stack” for the free desktop (i.e. GNU/Linux). I define a Universal Sound Stack as follows:

Any conjunction or configuration of sound daemons, libraries and frameworks that will permit every audio playback or capture application, which makes legal use of its audio API of choice, to play back and/or capture simultaneously, given sufficient system resources and no hardware mixing

Properties of Universal Sound Stacks

1. Since there are theoretically infinite sound APIs (proprietary software written inside companies; APIs for specific situations like hard real-time or smartphones; fringe APIs for devices like FireWire audio; etc.) any “Universal” sound stack is necessarily not universal in the strong sense. No matter what you do, I could go write a new sound API of my own invention and make it intentionally incompatible with your proclaimed universal sound stack, thus making your universal stack not strictly universal.

Therefore, let’s revise our definition of “universal":

A set of sound APIs that are (a) popular; (b) used prevalently in the targeted environment domain (desktop, embedded, pro audio, etc); or just c) used by an application that is desired.

2. Any Universal Sound Stack must employ one or more libraries or daemons that either implement or are targeted by (as a backend) every sound API that we want to enable.

3. For a “general purpose” Universal Sound Stack, the sheer number of well-supported sound APIs is the most important factor. Possibly losing support for one API is usually acceptable if we can preserve a great number of others in return.

4. A maximally universal Sound Stack is one which supports the most sound APIs (and uses thereof) that is practically feasible given the current state of the technology.

5. Every Universal Sound Stack must be evaluated based on actual implementations of the stack, and actual applications using it. There are a ridiculous number of instances of audio paths that are “in theory” supported, but “in reality” they either perform poorly, produce incorrect audio, or don’t work at all. The requirements of each problem domain must be applied to determine whether each audio path meets the expectations of the user. For example, desktop users might consider a 750 ms audio latency acceptable, but likely not pro audio users.

6. Every Universal Sound Stack must have a final chain of one or more elements that lead directly to the audio hardware. The final chain is “unbreakable": audio applications and libraries can interface with only the topmost element of the chain. At some point during the final chain, software mixing must be performed, so that hardware lacking the same can play audio from multiple sources at once.

7. A Universal Sound Stack is not unique. There is almost certainly another equivalent stack that enables the same set of APIs/applications. Each stack is simply one way to slice the pie. Different stacks can enable different APIs/applications or yield different performance characteristics (better quality, lower latency, etc.)

8. If it can be demonstrated that a given sound stack is a proper superset of another, then we should disqualify the lesser one from being “Universal” at all, even using our soft definition. This is a way to set the quality bar as high as possible for admission into the realm of being called a “Universal” Sound Stack. Otherwise, someone would have a Universal Sound Stack (in an extremely limited sense) just by installing ALSA.

Pages: 1 · 2 · 3 · 4 · 5 · 6 · 7