Garrett:
There are no plans to integrate PulseAudio on Solaris currently. It's
main value is to add per-application mixing support. This is useful if
you use ALSA which has no per-application mixing support, but this
feature is not so useful when using OSS since OSS already has such
support directly.
Another interesting PulseAudio feature is that it supports "Glitch-Free
Audio", though I understand OSS would need some non-trivial enhancements
to work with this feature. I don't believe there are any plans to do
this sort of PulseAudio integration in Solaris OSS.
http://fedoraproject.org/wiki/Features/GlitchFreeAudio
Other PulseAudio features (such as being able to switch audio to a
different stream on sound-card hotplug and positional sounds) are
kind of interesting, but I don't think interesting enough to warrant
the amount of work it would take to integrate PulseAudio. As you
highlight, Garrett, making all Sun audio programs talk directly to
PulseAudio is, by itself, a fair bit of work. Also, some of these
features would likely make more sense to integrate into OSS directly
(such as hotplug support).
Brian
> Thanks for the clarification.
>
> Supporting PulseAudio is something another team could undertake at some
> point. However, in order for it to work properly, there are a few things:
>
> 1) all the applications would have to be converted to it. (In the Linux
> distro world, where all apps are delivered with the distro, and there is
> no binary compatibility guarantee, nobody cares. In the Solaris world,
> this could create headaches as applications would have to be converted
> to understand PulseAudio.)
>
> 2) PulseAudio itself would need to be ported to Solaris/Boomer. This
> probably isn't a big effort.
>
> 3) IIUC, PulseAudio doesn't have a way to express the richness of the
> hardware device control that we'd like. (For example, being able to
> adjust the level of a particular analog output independently of the
> others, or being able to change the function of a jack or configure jack
> sense.) I think PulseAudio relies on the underlying subsystem to
> provide this -- and for Linux that usually means alsa with its rather
> Byzantine configuration files and tools. I don't think that's terribly
> workable for Solaris.
>
> -- Garrett
>
> Brian Cameron wrote:
>>
>> Garrett:
>>
>>> Its not in the g-v-c code today. But it looks to me like Fedora is
>>> aiming for a PulseAudio based implementation, which has its own issues.
>>> If people really want the per-application controls in g-v-c, they can
>>> be added, but its just a time thing. I'd prefer to deal with such a
>>> request as an RFE rather than a TCR.
>>
>> Note the GNOME "gnome-media" module contains two "gnome-volume-control"
>> applications, starting with gnome-media version 2.25. One of them
>> is called "gst-mixer", and this is the GStreamer based one that we
>> have always used. There is also a new "gnome-volume-control" which
>> uses PulseAudio. It seems that most distros which use PulseAudio are
>> going to switch to using the PulseAudio based one, while distros which
>> do not use PulseAudio (or have problems with it) will continue using
>> gst-mixer.
>>
>> This was discussed at length on the GNOME desktop-devel-list.
>> Unfortunately, the thread is a mix of different issues, not just related
>> to PulseAudio. However, here are a few emails from that thread if you
>> have an interest to learn more about what the community is doing:
>>
>> http://mail.gnome.org/archives/desktop-devel-list/2009-January/msg00208.html
>>
>> http://mail.gnome.org/archives/desktop-devel-list/2009-January/msg00239.html
>>
>> http://mail.gnome.org/archives/desktop-devel-list/2009-January/msg00240.html
>>
>>
>> Brian
>
