PSARC 2008/318 Boomer - potential issues

[Garrett D'Amore]

I wanted to record some potential issues we've found.  This stuff needs 
to be in our case materials before final commitment review, but at some 
level, we've not decided how to handle all of them, so I'd appreciate it 
if anyone has any special insight.

1) Port definitions and Sun audio(7I).  Sun APIs has definitions for a 
number of possible output ports, but the full set is less than what OSS, 
or even modern hardware, can express.  For example, there can be 
additional auxiliary input and outputs, video input, etc.  The Sun APIs 
could easily be expanded to include the additional ports we have so far, 
since there are plenty of bits left in the bit array.  The problem is 
that legacy applications may not be coded with knowledge of these bits, 
and I'm not sure how they will react in the presence of additional 
bits.  I'm inclined to just go ahead and add new port definitions 
anyway, and file bugs against applications that break as a result.   
Does anyone have any additional suggestions?

If the ability to query or change port settings (at least with values 
that reflect actual hardware settings) is reserved for control 
applications, then perhaps this limitation will go away -- see point 6 
below.

2) Expression of additional kinds of volume controls and Sun APIs.  If 
an application, such as sdtaudiocontrol, uses the Sun APIs to manage 
levels of a "foreign" (e.g. OSS) application, it may not be able to 
control all of the virtual levels associated with the application.  
(Because Sun's rather simplistic API consists solely of a single gain 
and balance.)  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.

3) An alternate option would be for us to expand the ioctls for the 
legacy Sun API to include support for these other channels.  In fact, 
for *playing*, there is no real inherent limitation in the Sun APIs.  
The issue comes in the implementation, and in the *control* API.  (You 
can stream as many channels as you want with the Sun API, but you can't 
adjust levels for more than 2 channels.)  I'm inclined for now to punt 
on this, and push applications towards OSS (wants we are ready to bless 
OSS as a committed API.)

4) Multiple inputs.  There is no real restriction on the number of 
inputs that can be active at a time.  E.g. you could be mixing a CD and 
a microphone input at the same time (think Karaoke).  Sun APIs don't 
support this.  Again, this isn't a problem for regular apps, because 
they don't expect to be able to do this -- but control apps only.  I'm 
again thinking that control apps should be written to the OSS API.

5) Separation of monitor sources and record sources.  Many chips (most?) 
allow the set of monitor devices to be selected independently of the set 
of record devices.  So you could be playing music from a CD, but only 
'recording' the input from a headset mic being used for VoIP.  Sun can't 
express this.  Again, only an issue for control apps.

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.

7) Potential power(9e) regression for legacy device drivers.  Right now, 
for some legacy SPARC devices (e.g. audiocs, audiots), our work to 
convert these devices to "Boomer native" devices has been done, but we 
have not done the work to make these devices fully support power(9e).  
(There are some challenges here, because the pm interfaces are not safe 
to call in streams context, an area that was a latent bug in some of the 
audio drivers!)   While we could tackle this, we believe there is little 
merit in the effort involved -- the amount of actual power saved is 
probably quite small, particularly relative to the power consumed by the 
CPUs on these systems.  We'd prefer to skip this effort, and take the 
small regression.  This might take some of these systems out of 
energystar v2 compliance, but as we believe that these systems are not 
in use in applications that are sensitive to power consumption, and as 
they are no longer marketed, we don't believe this should be a serious 
problem for anyone.   If anyone feels strongly otherwise, we'd like to 
know.  (Note that we do support platform power management via 
suspend-to-disk on the platforms that are capable of it.)

Thanks.

    -- Garrett