On Wed, May 5, 2010 at 7:13 PM, Ryan Oram <r...@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 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
