>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) 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. Casper
