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