Positional audio is the one feature that I see being useful in 
PulseAudio, which we don't have, and are unlikely to be able to easily add.

All of the other tasks are easy to add.

As far as per-application volume -- yes we have it in OSS -- but we 
don't have a way to *access* it from a central panel.  To address that 
would require modest effort to improve Boomer and Gnome-volume-control.  
(Its about 3 days of effort, I think.)

    -- Garrett

Brian Cameron wrote:
>
> 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
>>
>


Reply via email to