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

[Michael Bender/MBP]

Dev Mazumdar wrote:

 > The parts to solving Sun Ray support already exist - assembly
 > work is needed.

I'm not sure what that means. What I am sure about is that I
see a number of OSS cases coming before PSARC to request review
so that they can integrate their components into Solaris. Nothing
wrong with that, however I don't see any of the activity on how
to get Sun Ray support in OSS (or using the OSS API) that was
promised when we met last year. I am naturally worried that the
Sun Ray support will fall by the wayside and we will wind up
with two incompatible audio APIs/stacks/hardware support in
Solaris which will only server to confuse and frustrate customers.

My request to PSARC is to make sure that the OSS team has as a
high priority a plan in place to provide Sun Ray support using
the OSS APIs. Your comment above doesn't make me feel warm and
fuzzy that there is such a plan nor that there is actual work
going on to make this really work.

mike

----

> Michael Bender/MBP wrote:
>> These are general comments on the OSS project, and not all are
>> specific to this particular fastttrack, so I'm sorry for hijacking
>> this thread.
>>
>> I would like to note that the OSS project does not seem to have
>> taken Sun Ray audio support into account. Sun Ray and the pervious
>> OSS team (Margot, Vicki and 4Front) had an agreement that 4Front
>> and OSS would come up with a solution to allow OSS to work in a
>> Sun Ray environment, however I have not seen any work progress in
>> that area. The following fast track also doesn't seem to address
>> any environment other than the single-user workstation model.
>>
>> I would like to strongly suggest that PSARC give a directive to
>> the OSS team to consider the multi-user environment such as a
>> Sun Ray server or other multi-user environments that require
>> multiple distinct audio paths through the system to multiple
>> distinct audio hardware devices.
>>
>> What I have seen in the OSS project so far is an effort to take
>> code form 4Front and put it into Solaris in order to support
>> some additional audio hardware - that's fine, since we do need
>> to be able to support newer audio hardware - but I also see that
>> the project proposes to integrate a userland and kernel framework
>> that is completely unaware of a multi-user environment such as
>> Sun Ray. I do not want to debate the merits of the OSS API as
>> opposed to the SADA API - others have gone down that path - but
>> what I do want to emphasize is that the OSS project, as it now
>> stands, has a very good chance of disrupting the Sun customer
>> base that is using popular Sun technologies such as Sun Ray
>> and GNOME (assuming that the plans to switch GNOME to using
>> OSS rather than SADA materialize) if apps and window systems
>> convert to the OSS API, have no way of using SADA at runtime,
>> and if the OSS project provides the only practical, supported
>> audio API in Solaris going forward (SADA shim notwithstanding).
>>
>> I would like to request that PSARC provide some strong
>> architectural guidance in this area so that we don't wind
>> up with a big mess down the road.
>>
>> thanks,
>> mike
>>
> 
> 
> Hi Mike,
> 
> The rough idea for Sun Ray is a special OSS version (OTOH it may be 
> possible to integrate the required functionality to the stock version). 
> This version consists of the OSS framework, vmix (streams mixing engine 
> for record/playback) and audioloop (which is a pseudo "hardware driver")
> 
> Please see the following link for the source to audioloop.c
> http://manuals.opensound.com/sources/audioloop.c.html
> 
> 
> 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).
> 
> The /dev/dsp device is a symbolic link to the client side of the 
> audioloop driver. When an application opens /dev/dsp it gets connected 
> to the audioloop instance that matches the UID. An vmix engine is 
> created dynamically for the client device. If more applications open 
> /dev/dsp a new vmix engine gets created. In this way applications can 
> always open /dev/dsp and they will get redirected to the right server 
> process which is connected to the Sun Ray client. There is no need to 
> modify the applications to use some shell variable to find the right 
> device to use.
> 
> Real audio devices in the system are hidden from apps other than 
> processes running as root. Same way the real /dev/audio is hidden in 
> current design.
> 
> SADA emulation can probably be handled in the way we do it now.
> 
> 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.
> 
> The parts to solving Sun Ray support already exist - assembly work is 
> needed.
> 
> 
> 
> 
> 
> Best regards,
> 
> Dev Mazumdar
> -----------------------------------------------------------
> 4Front Technologies
> 4035 Lafayette Place, Unit F, Culver City, CA 90232, USA.
> Tel: (310) 202 8530        URL: www.opensound.com
> Fax: (310) 202 0496         Email: info at opensound.com
> -----------------------------------------------------------