PSARC 2008/318 Boomer - potential issues

[Garrett D'Amore]

Brian Cameron wrote:
>
> Garrett:
>
>> I think that as part of our implementation, we will convert the main 
>> control applications to the full featured OSS API, and just punt on 
>> this problem -- control applications using Sun audio(7i) won't be 
>> able to adjust surround levels, etc.
>>
>> 6) This seems to be leading us toward the road that we should, once 
>> OSS APIs become available everywhere, deprecate the use of Sun audio 
>> for mixer and control applications.
>
> Since GStreamer supports a plugin-in approach, it can support both
> SunAudio and OSS and let the user pick which mixer controls they want to
> use in gnome-volume-control at run time.  The only question is which
> should be used by default.  As you say, in the long run, OSS makes the
> most sense.
>
> One factor which could affect the default choice is Sun Ray.  I am not
> sure we can switch to using OSS mixing controls by default until the Sun
> Ray support is done.  Otherwise, won't audio just break for any Sun Ray
> users?  Maybe we don't care, but I thought we were trying to promote
> Sun Ray usage on OpenSolaris.

Sun Ray is in fact the only hold out here.

We're working in parallel on Sun Ray support, but there are some issues 
with Sun Ray support:

1) Sun Ray isn't supported officially on OpenSolaris yet.  And the Sun 
Ray team hasn't given me a time frame for when it will be.

2) There is additional complexity in the code, that might required a 
phased delivery.

3) There is a substantial challenge for OSS applications (the OSS API) 
on  Sun Ray.  That is, these applications have not been coded to look 
for $AUDIODEV in the environment file.  So we need to have some kind of 
virtual device in the kernel to reroute audio to the userland utaudio 
daemon associated with the user's session.  *That* requires a mechanism 
to be able to identify the Sun Ray session a process should be running 
under, which means some new API and probably a new field or two in the 
uarea.  And *that* is an architectural change that will need to be 
designed and reviewed separately.

So, the above issues result in us "deferring" Sun Ray support to Phase 2.

Note that if we only have to support GStreamer, and if GStreamer is 
willing to identify the Sun Ray session ID for us (e.g. with a new 
ioctl, or by opening a different file), then we could make those APPs 
work fairly easily.  I was trying to find a solution which didn't rely 
on modification of userland code, though.  (I have hypothesized that 
there are interesting audio applications which use OSS, and which are 
not based on GStreamer.)

    -- Garrett

>
> Brian
>