so i assume that in the man page below you'll be doing
s/mixerctl/audioctl/. if that's the case then i wonder about the need
for AUDIODEV support. AUDIODEV normally points to SADA style audio
devices, right? but since your introducting a new audioctl tool,
shouldn't it be designed to work on boomer audio devices, not SADA
devices?
ed
On Fri, Nov 13, 2009 at 07:22:40PM -0800, Garrett D'Amore wrote:
> Missing new page (sorry I forgot to hit the attach button!):
>
>
> User Commands mixerctl(1)
>
>
>
> NAME
> mixerctl - audio mixer control command line application
>
> SYNOPSIS
>
> mixerctl devices
>
> mixerctl info [-v] [-d device ]
>
> mixerctl get [-v] [-d device] [control ...]
>
> mixerctl set [-v] [-d device] control value
>
> mixerctl save [-d device] file
>
> mixerctl restore [-d device] file
>
> DESCRIPTION
> The mixerctl command is used to control various features of
> the audio mixer and to get information about the audio mixer
> and the audio device.
>
> The mixerctl command operates on the following data types:
>
> device
> A mixer device, such as audiohd:0. The subcommands
> that accept this do so as an argument to an option -d.
> If not supplied, then the default audio device is assumed.
>
> control
> A mixer control name, such as "volume".
>
> value
> The value of a control. The specific format depends on
> the type of control. Monophonic values usually use a single
> whole number between 0 and 100, inclusive. Stereo values
> use a pair of such numbers (representing right and left
> channels.) Boolean values indicate either "on" or "off".
> Enumerations take a single value of one or more names.
>
> file
> An ASCII text file of control settings.
>
> Options:
> Each subcommand has its own set of options that it takes.
> However, some subcommands support the special flag -v, which
> indicates a request for more verbose output.
>
> SUBCOMMANDS
> The following subcommands are supported:
>
> mixerctl devices
>
> List all the mixer devices on the system.
>
> mixerctl info
>
> Display general information about a device.
>
> mixerctl get [-v] [-d device] [control ...]
>
> Display the control setting values for the device. The named
> controls are displayed. If no control names are provided, then
> all control values are displayed.
>
> mixerctl set [-v] [-d device] control value
>
> Changes the value of a control to the supplied value.
>
> mixerctl save [-d device] file
>
> Saves the current state of all mixer control values to the named
> file.
>
> mixerctl restore [-d device] file
>
> Restores previously saved state in the named file for all mixer
> controls.
>
>
> ENVIRONMENT VARIABLES
> AUDIODEV If the -d and -a options are not specified, the
> AUDIODEV environment variable is consulted. If
> set, AUDIODEV contains the full path name of the
> user's default audio device. The default audio
> device is converted into a control device, and
> then used. If the AUDIODEV variable is not set,
> /dev/audioctl is used.
>
>
> FILES
> /dev/audioctl /dev/sound/{0...n}ctl
>
> ATTRIBUTES
> See attributes(5) for descriptions of the following attri-
> butes:
> ____________________________________________________________
> | ATTRIBUTE TYPE | ATTRIBUTE VALUE |
> |_____________________________|_____________________________|
> | Architecture | SPARC, x86 |
> |_____________________________|_____________________________|
> | Availability | SUNWauda |
> |_____________________________|_____________________________|
> | Stability Level | See notes |
> |_____________________________|_____________________________|
>
>
> NOTES
> The mixerctl command and the subcommands are Committed.
> The human readable output from this command is Not An Interface.
> The device names, control names, and values are Uncommitted.
> The format of the state files used by the save and restore commands
> is Committed Private.
>
> SEE ALSO
> audioconvert(1), audioplay(1), audiorecord(1), open(2),
> attributes(5)
>
>
> Garrett D'Amore wrote:
> >Having just written this up, I just remembered, mixerctl was not
> >an original invention of mine, but an earlier (and now useless)
> >version of it existed in Solaris 10 and earlier. I can't make
> >these incompatible changes as the case stands.
> >
> >However, there is a simple fix, with the following modification:
> >
> >1) rename "this" mixerctl to "audioctl", which frankly is a more
> >descriptive name for the command.
> >
> >2) Supply a shell script wrapper in /usr/sbin/mixerctl that offers
> >the old equivalent command line functionality, modulo the fact
> >that you obviously cannot turn a mixer "off" in Boomer.
> >
> >Thanks.
> >
> > - Garrett
> >
> >Garrett D'Amore - sun microsystems wrote:
> >>The following case proposes some incompatible changes to an Uncommitted
> >>interface. However, since the interfaces involved were only
> >>introduced in
> >>snv_115, and are not included in any actual official product, I
> >>think we can
> >>safely fix this with a fast track.
> >>
> >>Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
> >>This information is Copyright 2009 Sun Microsystems
> >>1. Introduction
> >> 1.1. Project/Component Working Name:
> >> mixerctl improvements
> >> 1.2. Name of Document Author/Supplier:
> >> Author: Garrett D'Amore
> >> 1.3 Date of This Document:
> >> 13 November, 2009
> >>4. Technical Description
> >>Mixerctl Improvements
> >>
> >>PSARC 2008/318 introduced a new command, /usr/sbin/mixerctl,
> >>which could be
> >>used to adjust settings for audio devices.
> >>
> >>However, there are several problems with the current implementation, and
> >>this case seeks to improve these.
> >>
> >>1) Usability: the names of audio devices displayed are not the
> >>same as names
> >> used for the command line parser. (Display uses "audiohd#0",
> >>but command
> >> requires an actal /dev name to be supplied, e.g. /dev/sound/0ctl.
> >>
> >>2) Usability: the use of getopt() instead of subcommands for all values
> >> makes using the command a bit awkward. We believe subcommands with a
> >> few "main" parameter arguments (such as the precedent set by
> >>zoneadm and
> >> the ZFS administration commands) is more intuitive.
> >>
> >>3) Usability: the command is supplied in /usr/sbin, where it is
> >>not on the
> >> default path for many users.
> >>
> >>4) Commitment: the single Uncommitted binding previously used was a bit
> >> vague, and in some cases inaccurate. A significant clarification is
> >> called for.
> >>
> >>Specific Changes:
> >>
> >>1) Device names generated on output will be of the form
> >>"driver:instance",
> >> and will be usable as arguments when a device name is called for.
> >>
> >>2) A completely new command syntax, specified in the attached man page,
> >> shall replace the old syntax. The new syntax uses major
> >>subcommands to
> >> split apart major functionality, and should be a lot more intuitive.
> >> (E.g. to change the master volume to 50 percent, one can just execute
> >> "mixerctl set volume 50")
> >>
> >>3) The command will be moved to /usr/bin. We can leave a
> >>symbolic link in
> >> /usr/sbin, but we see little merit in doing so as the
> >>original case was
> >> Uncommitted and the command has not been in any offical
> >>product release yet.
> >>
> >>4) The man page supplies much more detail about the exact commitment
> >> levels:
> >>
> >> The mixerctl command and the subcommands are Committed.
> >> The human readable output from this command is Not An Interface.
> >> The device names, control names, and values are Uncommitted.
> >> The format of the state files used by the save and restore commands
> >> is Committed Private.
> >>
> >>
> >>
> >>6. Resources and Schedule
> >> 6.4. Steering Committee requested information
> >> 6.4.1. Consolidation C-team Name:
> >> ON
> >> 6.5. ARC review type: FastTrack
> >> 6.6. ARC Exposure: open
> >>
> >
> >
