[Fwd: [Fwd: PSARC 2008/043 Phase 1 of OSS for Solaris]]

[Michael Bender/MBP]

Casper.Dik at Sun.COM wrote:
>> On Wed, Jan 23, 2008 at 01:44:19PM -0800, Dev Mazumdar wrote:
>>> There is a sound server process for each client. The server process 
>>> opens the server side device of audioloop. The audioloop driver creates 
>>> a new device instance (client/server device pair) and binds it to the 
>>> UID of the user (I assume they use UID to identify the sessions).
>> So if I have multiple sessions on the same server then one session will
>> get all the sound for all of them while the others get no sound?
>>
>>> The main problem is to make OSS to scale to up to 100k clients without 
>>> using all available memory. It will also take some time to get OSS to 
>>> use UID or some other client identification to redirect access to the 
>>> right server.
>> "some other client identification" seems like a better answer than "UID."
> 
> 
> Just to be sure: OSS will be either "optional" or used only for the
> devices it actually support and we can continue to use SunRays until it
> is fixed (I'm unsure why we'd even need to use OSS for SunRays)

There has been some talk by the GNOME folks to build GNOME to
only use OSS as the audio API for GNOME and GNOME apps. If this
were to happen, and Sun Ray did not have OSS API support (however
that is actually implemented), then GNOME audio would stop working
on Sun Ray.

> The reason Sun Ray uses $AUDIODEV and device entries in /tmp
> is a simple down-to-earth one: the kernel has no way of knowing what
> session you're in and so the Sun Ray service must offer the appropriate
> device.
> 
> The kernel does not have the information where to send to audio when
> a "virtual" device is opened in the case of Sun Ray.  Therefor the
> decision cannot be made where to send to audio inside the kernel; the
> decision must be made outside OR a new mechanism will need to be defined.

That is something that we are looking at doing, but we don't have
any firm plans in that are right now.

mike