Comment 45 for bug 579300

Dear Mr Chen,

I have been following this thread with interest from two distinct points of view:

- I am the author of an out-of-tree audio-video device driver which works fine under Ubuntu 10.04 LTS but is silent under Ubuntu 10.10, and I need to decide what to do about it:

http://sourceforge.net/projects/easycapdc60/develop

- I am also an ordinary Linux user who prefers things to Just Work, like everybody else.

I have no special expertise in Linux audio, and not much interest in it (the audio signal is merely a linear string of bytes - what's all the fuss about?). When I perform Google searches on the OSS/ALSA/PulseAudio wars I see a lot of vituperative anecdotes, but none of these really explain what's at stake, and I'm too lazy to trawl the specialist mailing lists of the past five years to find the tiny minority of postings that would throw light on strategy options for tackling technical issues. In my ignorance, then, I have the following simplistic view of the present situation:

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

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

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

If I decide that I need to add ALSA to my device driver, I'll do it. Maybe a little grumpily, but it's no big deal. To help me in making that decision, I'd appreciate your brief comments on the following.

(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? (Obviously I'm not interested in superficial differences like desktop bling.)

(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. My question is: 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?

(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?

(4) In the same post you state "Progress is always painful; some people's use cases will always be underserved with the new configuration. This is unfortunate,..." and in an earlier post you say "some people will always be hurt by the eliminated backward compatibility, but the long tail cannot be allowed to prevent consolidation". These are plausible arguments, and your unflinching willingness to take casualties is admirable. However, I think you'll 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"?

(5) My final question relates more generally to the decision-making process within Ubuntu. You and your colleagues have taken a decision to remove a certain functionality from Ubuntu. That decision may well be correct - I don't have the knowledge to make an informed judgement on it. But the decision does have an adverse effect on a number of people, and the reality is that you have exercised *power* over those people. Not only over users by denying them a useful feature which they want, but also over developers, who are in effect coerced into taking remedial action or seeing their applications disabled. Such power can, of course, be justified if it does lead to the greater good of the greater number, even if this is achieved only in the longer term. But with power normally comes a measure of accountability. So my final question 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?

Mike