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
