Albert Lee wrote: > On Fri, 2008-03-21 at 18:48 -0500, Brian Cameron wrote: > >> Mario: >> >> >>> Thing is this, OSS is regarded to be the red headed stepchild in the Linux >>> world, >>> _but_ it's APIs are preferred over the messy ALSA (which offers OSS >>> emulation). >>> >> > Everyone still equates the real OSS with the ancient code still left >> in the Linux >> > kernel. >> >> Competition is good. People will start to appreciate the new OSS more >> when it is more ready for public consumption. Sun is probably to blame >> for it taking so long. >> >> >>> Anyway, from what I've gathered, especially with the announcement of >>> Pulseaudio >>> >> > being integrated into Ubuntu 8, everyone holds high hopes to it. If >> it's API is >> > clean and usable, maintenance on OSS plugins in various applications >> >>> might stagnate in favor of Pulseaudio ones. What doesn't help is that the >>> >> > project leader is "coincidentally" also spreading FUD about OSS. >> >> My understanding is that few applications are being written to >> PulseAudio. I believe even the PulseAudio maintainer recommends that >> applications not use the PulseAudio API directly but instead use it >> only indirectly via pluggable mechanisms like GStreamer. These same >> pluggable interfaces tend to also support OSS, so the existence (or not) >> of PulseAudio should be mostly invisible to end-users or people >> compiling code. Since OSS has many of the features that PulseAudio >> provides, these pluggable interfaces can simply make use of these OSS >> features when using their OSS plugin, rather than needing PulseAudio. >> >> I understand PulseAudio makes the most sense when you decide on a design >> where all audio programs all redirect their output through PulseAudio. >> I believe Red Hat and Ubuntu are hacking everything from esd to >> GStreamer, etc. to forward output to PulseAudio to achieve this. >> >> I'm not sure this design makes a lot of sense on Solaris, especially >> since OSS will provide many of the benefits that PulseAudio already >> offers. >> >> Brian >> >> > > I might be missing something here, but I am unfamiliar with the view > that PulseAudio is meant to address ALSA's shortcomings. I remember the > project's primary goal as Polypaudio was to rewrite Esound (which has > always been flaky) and extend it with network transparency. > > While old-school sound server tasks like mixing and sample rate > conversion are made obsolete by a modern sound architecture, PulseAudio > provides services outside of that realm, although its module system > might be considered to be conflicting with GStreamer. > > This is the first implementation of network-transparent audio that I've > seen gain critical mass (remember NAS?), and just for that I find it > very valuable. > > -Albert > > _______________________________________________ > desktop-discuss mailing list > desktop-discuss at opensolaris.org > I stand corrected on the intention, but nonetheless I agree that it's more of a novelty for some users. It could be said that network audio is useful for thin clients (For a conference room for example) or for streaming to say a PS3 from OpenSolaris to Linux, which would be neat. From another standpoint, it's unnecessary complexity to deal with. ESD as of 2 years ago, the last time I used it without resorting to using Alsa dmix settings, was still flaky, so I agree that PulseAudio is doing something right.
From the latest usage of Linux that I've done, it works well enough at least for those who have had ESD experience, but the API has yet to be wholeheartedly adopted, hopefully it will be. With some hacking I was able to get most proprietary apps to pipe directly through Alsa, there's still a few that just can't handle multitasking the sound server. James
