I'm filing this on my own behalf.  While the proposal is for EOF of a
closed source bit (sdtaudiocontrol), I think its fair for the
discussion to be in the open, so the case is left open.  The timeout
is set for Feb 16, 2009.  Thanks.


Template Version: @(#)sac_nextcase %I% %G% SMI
This information is Copyright 2009 Sun Microsystems
1. Introduction
    1.1. Project/Component Working Name:
         EOF sdtaudiocontrol
    1.2. Name of Document Author/Supplier:
         Author:  Garrett D'Amore
    1.3  Date of This Document:
        09 February, 2009
4. Technical Description

EOF sdtaudiocontrol
-------------------

Garrett D'Amore
Sun Microsystems, Inc.
Jan 26, 2009

Executive Summary:
----

As part of the Boomer project (PSARC 2008/318), we would like to EOF the
CDE application called sdtaudiocontrol, in favor of the
gnome-volume-control application.


Details:
----

1) sdtaudiocontrol is part of CDE, and is not delivered with
Gnome/JDS.  Hence it is unavailable on OpenSolaris, and, we believe,
ultimately doomed with the rest of CDE.  (Although it was explicitly
exempted from the rest of the CDE EOF in LSARC 2007/648.)

2) sdtaudiocontrol is the sole consumer of a number of APIs in the
SADA mixer framework.  The Boomer project would prefer not to have to
support those APIs.

3) The mixer APIs that sdtaudiocontrol uses are not expressive enough
to support the full richness that the Boomer project can support
(e.g. multichannel volume control, additional input and output ports,
etc.)  Another example are devices that can support multiple
simultaneous monitors with independent gain control -- legacy Sun
mixer APIs simply cannot express such a notion.

4) Updating sdtaudiocontrol to support use the OSS APIs is possible,
but would take considerable effort.  Additionally, the Boomer
implemenation of the OSS APIs would need to be enhanced to support
per-application volume controls.

5) The gnome-volume-control can do nearly everything that
sdtaudiocontrol does, and can support (with a suitable Gstreamer
plugin), complete device control, including all of the features Boomer
will deliver.  gnome-volume-control will operate on systems with CDE.

6) The Boomer project has already indicated that applications which
wish to adjust master hardware settings will have to be converted to
use OSS v4.x APIs that are supplied with Boomer.  Applications using the Sun
API will impact only a "soft volume" associated with the application, and not
have any effect on the global hardware levels.


Proposed Solution:
----

We propose to EOF sdtaudiocontrol altogether, along with a number of
the APIs of which it is the sole consumer.  (These are the APIs to
query and change individual application volumes.)  Any remaining mixer
and audio API will be altered in accordance with Boomer, such that
applications built upon them will only be able to impact their own
"per application" soft volume.


Possible Concerns:
----

1) gnome-volume-control (today at least) has nothing akin to the
"application volume control" that sdtaudiocontrol offers.  Such a
feature could be added if it is deemed required.  (This would
potentially significantly complicate gnome-volume-control, since
applications can come and go, hence the set of controls offered would
need to be much more dynamic that it currently is.  There are other
issues even with sdtaudiocontrol's use of this feature, since many
applications perform their own "soft volume" attenuation in the
application such that no mixer application will ever be able to
synchronize properly.)  In the short run, we are proposing not to
deliver this feature.  (Again, note that this feature is not available
on OpenSolaris, today.)

2) Customers installing CDE without JDS will not have GUI access to
adjust audio settings including volume.  A command line application,
mixerctl, will still be available that will offer the full
functionality of gnome-volume-control.



6. Resources and Schedule
    6.4. Steering Committee requested information
        6.4.1. Consolidation C-team Name:
                CDE
    6.5. ARC review type: FastTrack
    6.6. ARC Exposure: open


Reply via email to