Comment 46 for bug 579300

> - OSS is bad, because of licensing issues in the past but more
> importantly because it does not properly share the soundcard (and its
> settings) between userspace applications.  Low latency though.

I won't delve into overtly political thrusts regarding whether OSS or
ALSA is good, per se (the latter was created partly because of
politics, but that isn't relevant here). I will say that many
(userspace) audio developers find the OSS API simpler. In the Linux
world, however, momentum lies with ALSA due to its high-profile
maintenance. Both OSS and ALSA offer some virtualization of
(de)muxing streams such that "properly shar[ing] the soundcard"
appears fairly transparent to the end user with the caveat that *all*
the applications in use must be fully supported, well behaved
non-abusers of *one* API.

Low latency isn't inherent to OSS. Its API can still be abused, but
the fewer context switches do offer something.

> - ALSA is good, because it is politically correct and resolves the
> soundcard sharing issue.  Latency might be a problem or might not.

From an audio developer's perspective, ALSA offers far more knobs to
twiddle. This complexity is both alluring and devastating. A
relative dearth of maintained library documentation certainly doesn't
help. In fact, the most up-to-date (and arguably, best) documentation
is actually the PulseAudio creator's linked from
http://0pointer.de/blog/projects/guide-to-sound-apis.html.

Again, higher latency with ALSA is inherent in more context switches,
but given the restrictions of Linux (rather, kernelspace), it makes
sense to handle the complexities and modularization (e.g.,
alsa-plugins) in userspace.

> - PulseAudio is popular with people who put together Linux distributions
> (not only Ubuntu), but it is unclear to me what problem in ALSA it is
> intended to solve.

PulseAudio's prime driver is the modern Linux desktop. If
insufficiently clear, it has never meant to supplant ALSA (and surely
it cannot, as it relies on a driver backend of some sort). However,
manipulating alsa-lib configuration files is nightmarish for more
familiar developers and users and downright insane for uninformed
ones. It brings a level of desktop use ease that, when coupled with
well behaved drivers, makes audio nary a consideration. Yes, of
course one could use nc(1) and aplay(1)/arecord(1) to mimick its
functionality, but doing so would still require an application
restart.

Let's be clear: PA isn't meant to supplant JACK, either; the former
traditionally was targetted toward less expensive internal High
Definition Audio chipsets/codecs; the latter, professional-grade
external audio devices. The use cases for either tend to be distinct
and thus have differing requirements.

> (1) If, as is likely, the outline of the distinction between OSS, ALSA
> and PulseAudio that I've given above is wrong, can you give me some
> links to authoritative articles which would put me right?

I've attempted (perhaps poorly) to distinguish the major points;
Lennart's guide above is far more authoritative.

> (2) My impression is that PulseAudio (and to a lesser extent ALSA)
> evolved as a response to the needs of audio "enthusiasts" - people
> regularly using multiple audio applications simultaneously and with
> high-specification, and possible multiple, soundcards.

Actually, I would say that PulseAudio's use case is for
non-enthusiasts given your statement above. It seems more likely that
people with "high-specification" (I'm interpreting this as
professional audio) cards would use JACK. PA benefits mostly people
who have an integrated audio device and, e.g., use a usb headset
additionally.

> what proportion of the Linux userbase (or the Ubuntu userbase) are
> "enthusiasts" in this sense?  It is useful to distinguish "enthusiasts"
> from "single-application" users, who want audio to work out the box for
> just one or maybe two applications, for example YouTube or some awesome
> game, and do not care much about audio mixing or ways of preserving
> audio settings.  I myself am a "one-application" user as defined here,
> and I do not object to manually tweaking a few volume controls on the
> rare occasions when it is necessary.  The question, then, amounts to:
> what percentage of the userbase are "one-application" users?

"Enthusiasts" as I've clarified above would use JACK mostly and
PulseAudio rarely. Most casual Linux desktop users aren't
enthusiasts, and there is little use in distinguishing between
single-use and multiple-use clients of the audio subsystem. It is far
too simple to "bleed" a "single-use" Skype session into playing a
YouTube video in a web browser. The audio subsystem has to handle
this nearly ubiquitous desktop use case.

I don't have hard percentages for desktop users, and I doubt that
anyone does. Anecdotally, however, in a coffee shop filled with
laptop users, few will be "enthusiasts."

> (3) You mention in an earlier post that the objection to allowing OSS
> emulation is that "it *prevents* all other programs from accessing the
> sound device concurrently".  If I am a "one-application" user and I
> choose to accept this limitation of OSS emulation, should I not be
> allowed to do so?

Of course you have been allowed to do so, but it is also a sticking
point in resolving defect reports. If someone uses "an OSS program"
concurrently with "an ALSA program", unless said user has an audio
device (or multiple audio devices) capable of hardware multiopen, one
of the OSS and ALSA programs will report a "device busy" error. This
is *far* more common than someone being aware of, and accepting, the
limitation of OSS emulation.

> agree that for such arguments to achieve ready acceptance it is
> necessary to demonstrate that the long tail really does contain the
> "one-application" users whereas the main body of users are
> "enthusiasts".  Otherwise the tail is wagging the dog.  So this question
> is really the same as question (2) above:  where is the evidence that
> the majority of the Ubuntu userbase are audio "enthusiasts"?

Lack of defect reports does not imply that there are no bugs.
Similarly, the vast majority of reported audio bugs in modern Linux
desktop distributions lie in driver or integration issues. Using
"non-enthusiasts" as I clarified above, it is far more common for bugs
regarding Adobe Flash integration with Skype (or, e.g., Movie Player,
Rhythmbox) to appear than for bugs regarding TV capture to appear.
Put another way, there are a non-trivial number of users who play
games and expect to be able to use an app like TeamSpeak/Ventrilo
concurrently, and this latter use case is again far more common than a
"single-use" one. Of course this doesn't diminish the validity of
single-use ones, but it does imply that using a different approach,
e.g., providing relevant backends (i.e., PulseAudio) is more likely to
address the common uses.

> is:  what is the mechanism within the Ubuntu management which ensures
> that decisions of this kind, possibly beneficial but also potentially
> damaging, are taken with proper regard for all the circumstances?

The most relevant links would be the Technical Architect and the
Technical Board. Please find more information at
http://allisonrandal.com/2010/08/20/ubuntu-ta-intro/ and
https://wiki.ubuntu.com/TechnicalBoard (and
https://wiki.ubuntu.com/UbuntuDevelopment/ReleaseProcess more
generally), respectively.