Removal of PulseAudio from Ubuntu

[Ryan Oram]

On Thu, May 6, 2010 at 12:46 AM, Daniel Chen <seven.steps at gmail.com> wrote:
> 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
>

I apologize if I was frank, but problem with PulseAudio is that it
does not always work with existing code.

Before OSS4 is implemented in infinityOS, I will make sure that
everything works out of the box with the OSS4 audio system. It will be
subject to a considerable amount of testing. This is partly to
maintain 100% binary compatibility with Ubuntu. I wish for infinityOS
to continue to work with the Ubuntu repos and PPAs as I feel
duplication of effort is unnecessary.

I hope to keep in touch and let you guys know personally how the system goes.

Thanks,
Ryan Oram