Edward Pilatowicz wrote:
> 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?
>   

Yes, it should have the "s/mixerctl/audioctl/".  I am going to have 
another set of updates, as since I've made changes to the code I've 
altered a few more things.

As far as $AUDIODEV goes, the code actually will work with either a SADA 
device node or a Boomer node.  The underlying code only operates on 
Boomer nodes, but it operates by finding the associated "mixer" device 
node for the device file you supply.

So it will work to supply any of:

    /dev/audio
    /dev/audioctl
    /dev/sound/0
    /dev/dsp
    /dev/dsp1
    /dev/sound/audiohd:0
    /dev/sound/audiohd:0dsp
    /dev/sound/audiohd:0mixer

The goal here is that end-users should not need to be aware of SADA vs. 
Boomer.  Those are API details.

    -- Garrett
> 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
>>>>
>>>>         
>>>       

Reply via email to