Removal of PulseAudio from Ubuntu

[Daniel Chen]

On Wed, May 5, 2010 at 7:13 PM, Ryan Oram <ryan at infinityos.net> wrote:
> It is 2 years old, but the facts in the article above are still
> completely true. PulseAudio has made essentially zero progress in the
> last 2 years, which is why it should be abandoned.

I feel I am at least somewhat qualified to speak on this subject,
having been involved in the (ill?) integration of PA in Ubuntu many
releases ago and for x86 driver quirking many years prior and since.

"Zero progress" really is stunningly ill-informed. Yes, there remain
problems with BIOS vendors, mainboard integrators, audio drivers,
alsa-lib, PulseAudio, application integration, and so on, but to claim
zero progress for any part of the audio stack is quite off the mark.
The fact of the matter is that audio deficiencies in any popular Linux
distribution raise polemics, none of which is truly on-mark. Perhaps I
can do a better job of documenting efforts to combat deficiencies, so
this thread is as good a place as any to continue.

Put another way: there are plenty people who decry the sinkhole, but
who's actually fixing the structural problems that led to the
sinkhole?

For the past ten years I have seen similar cycles of specifications
being published (along with errata) and OEMs leaping to implement
attractive features at the expense of doing a good job documenting
their quirks (much less implementing standard quirk interfaces -- and
vendors of usb components are only slightly less worse than pci
components). This leads to spaghetti code in audio drivers, some of
which are marginally less hair-loss-inducing than others. The
traditional ALSA driver semantics are interrupt-based. PulseAudio,
with its emphasis on preventing excessive power consumption through
timer-based buffering, expects the underlying driver to duly provide
precise and accurate information. For the past three years this
approach has utterly destroyed any semblance of "stability" in the
audio stack -- for good reason: the drivers incorrectly assumed the
underlying hardware duly acted precisely and accurately. We've been
fixing these drivers as such symptoms appear, and we're by no means
finished -- nor do I expect we'll ever reach such a milestone.

What happens when you have hardware or a driver that acts imprecisely
and/or inaccurately? You get some utterly disappointing results as
exposed through PulseAudio's glitch-free (standard in Karmic and
Lucid) mode. Does this mean that PA is faultless? Of course not; we
should do a better job, among many things, by reverting to the
traditional interrupt mode. Does this mean that the driver should be
fixed? Absolutely. Does replacing ALSA wholesale with OSS resolve the
issue? No; we'd only replace one problem domain with another, and we'd
still need to maintain all versions with ALSA support *and* continue
forward with hardware enablement. This means that you now have to sets
of mouths to feed. Various upstream developers of programs
incorporated in Ubuntu don't necessarily address the complexities of
having *supported* derivatives that deviate from Ubuntu's base, and
this issue is particularly telling with respect to the audio stack.

Canonical has/will recently brought/bring on board knowledgeable audio
hackers. I expect the situation to improve, not worsen. While I
applaud your efforts to bring a more usable audio experience
out-of-box to casual users, I cannot help but muse that our
(volunteer) efforts are better spent improving parts of the stack that
most need help: ALSA driver and either PulseAudio or Jack Audio
Connection Kit.

> Open up any emulator program on Ubuntu and it will skip like mad. Same
> with many native games such as Lincity-ng or OpenSonic. This is as
> most games on Linux depend on sound timing, which the high latency
> nature of PulseAudio messes up.

PA is happy to grant high latency by default because doing so is more
friendly to lower power consumption. Various pulse clients (whether
frameworks like SDL or OpenAL-soft) have been fixed to properly
specify latency requirements and act accordingly.

I cannot emphasize enough the need to fix the underlying drivers.

> A good possible solution would be switching to OSS4 and writing an
> audio wrapper for it to make it easier for developers to use. OSS4 is
> much more simplistic and (arguably) cleaner designed then ALSA, which
> would likely made this an easier task.

Your distribution seems like a great place to test such a hypothesis.
Please test backward compatibility with native ALSA and PulseAudio
applications, too!

Best,
-Dan