Calum: >> I do hope the desktop community pays keen attention to these issues >> and never ships Pulse Audio and works to improve GStreamer which is >> the right framework. > > As far as I'm aware, gstreamer sits higher in the stack than PulseAudio, > so GNOME distros that use PulseAudio still have to use gstreamer as well.
GStreamer is a very flexible framework. There is no reason why you could not write a userland audio mixer server (like PulseAudio) with GStreamer if you wanted. GStreamer is also designed to be used by media streaming servers, and there are a few applications which use it like this. However, it is true that GStreamer does typically sit higher in the stack than PulseAudio when used in most desktop applications. That said, PulseAudio is trying to solve a different problem than the way GStreamer is typically used on the desktop. Most desktop programs call GStreamer interfaces to send audio to the correct output sink. On Solaris, this is typically sending audio directly to the OSSv4 interfaces. When PulseAudio is used, GStreamer-based applications can easily send its output to it instead. PulseAudio acts as a userland mixing server which accepts all audio streams that the user wants to play. It then provides the ability to do per-application mixing. This is useful if you have multiple programs playing audio at the same time. You can change the volume levels of different programs in a single GUI. I am not sure if this is really a critical feature, though. Most audio programs have volume control sliders directly in the application where users can set the volume in a per-application fashion. OSSv4 does support per-application mixing, though it currently is not exposed in the Solaris desktop. Some effort would be required to plug existing audio applications into its framework so this would work. So, I think that we need to carefully consider which approach (using PulseAudio or OSSv4 mixing capabilities) is the best one to pursue for OpenSolaris. In my opinion, the main problem with integrating PulseAudio is that all audio programs need to send their audio output to PulseAudio for it to work properly. Solaris currently ships a lot of programs that still talk directly to SunAudio (e.g. Flash, RealPlayer, Ekiga). While it is pretty easy to make GStreamer-based programs talk to PulseAudio, it would be a significant amount of effort to rework programs like Flash, RealPlayer, and Ekiga to talk to PulseAudio. PulseAudio does also offer some other neat features like directional sound (e.g. an event sound from a window on the left side of the screen could play louder in the left speaker), which may be useful in some a11y situations. When using ALSA, it also has some nice "glitch-free" code. However, it would be significant effort to make this work with OSSv4, and it might make more sense to just implement glitch-free directly in OSSv4 rather than use something like PulseAudio. I would not say that Sun is against integrating PulseAudio. As I mention above, there is some significant effort involved with integrating PulseAudio on Solaris. The advantages of using it with OSS are not as dramatic as when it is used with ALSA. If we discover some compelling reason to integrate PulseAudio in the future that would justify doing this work, then of course we would consider it. Brian
