+1
On Mon, 2009-02-09 at 08:46, Garrett D'Amore wrote:
> John Fischer wrote:
> > Garrett,
> >
> > This project appears to be deprecating the sdtaudiocontrol
> > application in a Patch release of Solaris and removing it in
> > a Minor release of Solaris. Correct? If so then the interface
> > is Obsolete Uncommitted. What about the SADA mixer framework?
> > Are you doing the same for it as well?
> >
>
> Yes, sdtaudiocontrol would be Obsolete Uncommitted in the next S10
> release, and removed in whatever Solaris release follows.
>
> May folks are confused by the name "SADA". SADA applies to the
> in-kernel interfaces. Those interfaces were never public, and so their
> removal requires no notice.
>
> However, the mixer(7i) API *is* public. Those interfaces will be marked
> Obsolete Uncommitted. The details of how these are being affected is
> really more relevant for PSARC 2008/318 than here, but suffice to say
> that some of the semantics are being changed in ways to allow ordinary
> audio applications to operate properly, but which will require
> applications which wanted to control the audio mixer directly (as
> opposed to managing their own playback or record levels) to use the new
> OSS API.
>
> Note that *this* case is not to approve the changes being made as part
> of PSARC 2008/318, other than to explain them as a motivation for the
> key aspect of the case, which is the EOF sdtaudiocontrol.
>
> -- Garrett
> > Thanks,
> >
> > John
> >
> > On Mon, 2009-02-09 at 07:46, Garrett D'Amore - sun microsystems wrote:
> >
> >> 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
> >>
> >>
> >
> >
>
