You both make perfectly valid points, but I think you don't put the stress exactly where you should, so... sorry for the spam:
1) The ideal situation would be that all applications have native PulseaAudio output, to take advantage of it's great features. Corollary 1a. Bugs in any application's PA module are the application's fault, and should be fixed in the application. This minimizes effort and cruft, and maximizes the opportunities for future development of PA. Corollary 1b. If this isn't true _now_ for an application, it can _only_ happen for future versions of it. Which means that only applications that i) already have PA support or ii) will add it in the future can be in this ideal situation. 2) The practical situation is that there will always be applications that don't have native PA support. In particular, many users will need (for too many reasons to cite here) to run an application like this. Often this is because they _need_ to use an old, not-still-developed application or version of it. That last part is important: even if application X is still worked on, if the user _needs_ an older version (say, because the new ones don't work, or is only 64 bit, or, like Skype, is developed primarily on Windows), they will need it supported. And there are always legacy applications. Corollary 2a. Support for ALSA/OSS/etc is by definition _legacy_ support, for applications that won't work with PA. Corollary 2b. We have this compatibility layer _because_ users _need_ to use things that don't fall into the ideal situation above, _and_ because if we don't have this compatibility PA will not see widespread use, developers will not add PA support in the future, and we'll get even further away from the ideal situation. Corollary 2c. Even if a legacy app. is broken, PA _needs_ to support it and work. This is important enough and hard enough to agree with that it deserves a re-statement: We don't want PulseAudio to have ALSA support. We don't care about ALSA in particular. We want PulseaAudio to have support for ALSA-only _applications_. Read that again: == We want PulseaAudio to have support for ALSA-only _applications_, not ALSA per-se. == (This applies for OSS and any other compatibility layer.) Whether or not these apps are broken _totally_ irrelevant! The compatibility layers are there, by definiton, for applications that are _not_ supported with PulseAudio. If their developers cared, they'd have added PA support anyway, and we wouldn't need the compatibility layer. If someone can run, say, Skype on ALSA (despite its brokenness) and they can't with PA, they won't use PulseAudio. We NEED such apps to be usable, so that people will use Pulseaudio, so that current developers have an incentive to add PulseAudio support. I know it's difficult, and I know it takes developer time, and I know they work for free, and I know the best thing would be to shut up and send a patch. But that doesn't change the truth of it. -- PulseAudio prevents programs relying on ALSA to work correctly https://bugs.launchpad.net/bugs/198453 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
