From gd78059@sac.sfbay.sun.com Fri Nov 13 18:45:59 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAE2jwca007945 for ; Fri, 13 Nov 2009 18:45:58 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id nAE2jtFZ001334; Sat, 14 Nov 2009 02:45:57 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KT200801VOKED00@brm-avmta-1.central.sun.com>; Fri, 13 Nov 2009 19:45:56 -0700 (MST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KT2007A5VOJA090@brm-avmta-1.central.sun.com>; Fri, 13 Nov 2009 19:45:55 -0700 (MST) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nAE2jtxA018312; Fri, 13 Nov 2009 18:45:55 -0800 (PST) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAE2jrXM007940; Fri, 13 Nov 2009 18:45:53 -0800 (PST) Received: (from gd78059@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id nAE2jrrU007936; Fri, 13 Nov 2009 18:45:53 -0800 (PST) Date: Fri, 13 Nov 2009 18:45:53 -0800 (PST) From: "Garrett D'Amore - sun microsystems" Subject: mixerctl improvements [PSARC/2009/626 FastTrack timeout 11/20/2009] To: PSARC-ext@sun.com Cc: Garrett.Damore@sun.com Message-id: <200911140245.nAE2jrrU007936@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 2889 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 From Garrett.Damore@sun.com Fri Nov 13 18:51:14 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAE2pDJs007976 for ; Fri, 13 Nov 2009 18:51:13 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id nAE2p6I2003747 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 14 Nov 2009 02:51:12 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KT200505VXAO200@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 13 Nov 2009 18:51:10 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KT2005BOVXAH800@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 13 Nov 2009 18:51:10 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAE2pAax001287 for ; Fri, 13 Nov 2009 18:51:10 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KT200I00VMNN800@fe-sfbay-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 13 Nov 2009 18:51:10 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KT2007RFVX9W0B0@fe-sfbay-10.sun.com>; Fri, 13 Nov 2009 18:51:10 -0800 (PST) Date: Fri, 13 Nov 2009 18:51:08 -0800 From: "Garrett D'Amore" Subject: Re: mixerctl improvements [PSARC/2009/626 FastTrack timeout 11/20/2009] In-reply-to: <200911140245.nAE2jrrU007936@sac.sfbay.sun.com> Sender: Garrett.Damore@sun.com To: "Garrett D'Amore - sun microsystems" Cc: PSARC-ext@sun.com Reply-to: Garrett.Damore@sun.com Message-id: <4AFE1B1C.7090204@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200911140245.nAE2jrrU007936@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091013) Status: RO Content-Length: 3687 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 > > From gdamore@sun.com Fri Nov 13 19:22:44 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAE3Mh76008824 for ; Fri, 13 Nov 2009 19:22:44 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id nAE3MS3g011331 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 14 Nov 2009 11:22:42 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KT200C01XDUMG00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 13 Nov 2009 20:22:42 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KT200760XDTAC90@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 13 Nov 2009 20:22:42 -0700 (MST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAE3MfRO001779 for ; Fri, 13 Nov 2009 19:22:41 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KT200400X5W4F00@fe-sfbay-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 13 Nov 2009 19:22:41 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KT2007MOXDSW0E0@fe-sfbay-10.sun.com>; Fri, 13 Nov 2009 19:22:41 -0800 (PST) Date: Fri, 13 Nov 2009 19:22:40 -0800 From: "Garrett D'Amore" Subject: Re: mixerctl improvements [PSARC/2009/626 FastTrack timeout 11/20/2009] In-reply-to: <4AFE1B1C.7090204@sun.com> Sender: Garrett.Damore@sun.com To: Garrett.Damore@sun.com Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com Message-id: <4AFE2280.2030005@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200911140245.nAE2jrrU007936@sac.sfbay.sun.com> <4AFE1B1C.7090204@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091013) Status: RO Content-Length: 7779 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 >> >> > > From edward.pilatowicz@sun.com Mon Nov 16 10:31:23 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAGIVNXP019944 for ; Mon, 16 Nov 2009 10:31:23 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id nAGIV7qe035299; Mon, 16 Nov 2009 11:31:22 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KT700513SS8OD00@brm-avmta-1.central.sun.com>; Mon, 16 Nov 2009 11:31:20 -0700 (MST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KT700E7VSS786C0@brm-avmta-1.central.sun.com>; Mon, 16 Nov 2009 11:31:19 -0700 (MST) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id nAGIVGDo626759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Nov 2009 10:31:16 -0800 (PST) Received: (from edp@localhost) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id nAGIVGoS626758; Mon, 16 Nov 2009 10:31:16 -0800 (PST) Date: Mon, 16 Nov 2009 10:31:16 -0800 From: Edward Pilatowicz Subject: Re: mixerctl improvements [PSARC/2009/626 FastTrack timeout 11/20/2009] In-reply-to: <4AFE2280.2030005@sun.com> To: "Garrett D'Amore" Cc: Garrett.Damore@sun.com, "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com Message-id: <20091116183116.GR523640@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200911140245.nAE2jrrU007936@sac.sfbay.sun.com> <4AFE1B1C.7090204@sun.com> <4AFE2280.2030005@sun.com> X-Authentication-warning: jurassic-x4600.sfbay.sun.com: edp set sender to edward.pilatowicz@sun.com using -f User-Agent: Mutt/1.5.20 (2009-06-14) Status: RO Content-Length: 8429 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 > >> > > > > From Darren.Moffat@sun.com Mon Nov 16 10:38:38 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAGIcb0e020288 for ; Mon, 16 Nov 2009 10:38:37 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id nAGIcWWh041962 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 16 Nov 2009 11:38:37 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KT700413T4BBL00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 16 Nov 2009 10:38:35 -0800 (PST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KT700LIVT49BI90@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 16 Nov 2009 10:38:34 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAGIcX6T009871 for ; Mon, 16 Nov 2009 18:38:33 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KT700800T1TTK00@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 16 Nov 2009 18:38:28 +0000 (GMT) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KT700MK9T3WOV90@fe-emea-09.sun.com>; Mon, 16 Nov 2009 18:38:21 +0000 (GMT) Date: Mon, 16 Nov 2009 18:38:20 +0000 From: Darren J Moffat Subject: Re: mixerctl improvements [PSARC/2009/626 FastTrack timeout 11/20/2009] In-reply-to: <20091116183116.GR523640@eng.sun.com> Sender: Darren.Moffat@sun.com To: Edward Pilatowicz Cc: Garrett.Damore@sun.com, PSARC-ext@sun.com Message-id: <4B019C1C.5050905@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200911140245.nAE2jrrU007936@sac.sfbay.sun.com> <4AFE1B1C.7090204@sun.com> <4AFE2280.2030005@sun.com> <20091116183116.GR523640@eng.sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091027) Status: RO Content-Length: 319 I think audioctl is a better name. However given the nature of mixerctl I personally would be okay approving incompatible changes to it for a Minor release binding. If it is trivial enough to keep mixerctl around with its current CLI and introduce audioctl, then great that sounds even better. -- Darren J Moffat From gdamore@sun.com Mon Nov 16 11:02:44 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAGJ2iGJ021053 for ; Mon, 16 Nov 2009 11:02:44 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nAGJ2gvq002029 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 16 Nov 2009 11:02:44 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KT70050NU8KQ000@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 16 Nov 2009 11:02:44 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KT700LM5U8IBPA0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 16 Nov 2009 11:02:42 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAGJ2gP8026448 for ; Mon, 16 Nov 2009 11:02:42 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KT700I00T9KGR00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 16 Nov 2009 11:02:42 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KT700EKWU8A8H20@fe-sfbay-09.sun.com>; Mon, 16 Nov 2009 11:02:35 -0800 (PST) Date: Mon, 16 Nov 2009 11:02:34 -0800 From: "Garrett D'Amore" Subject: Re: mixerctl improvements [PSARC/2009/626 FastTrack timeout 11/20/2009] In-reply-to: <20091116183116.GR523640@eng.sun.com> Sender: Garrett.Damore@sun.com To: Edward Pilatowicz Cc: Garrett.Damore@sun.com, "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com Message-id: <4B01A1CA.7060308@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200911140245.nAE2jrrU007936@sac.sfbay.sun.com> <4AFE1B1C.7090204@sun.com> <4AFE2280.2030005@sun.com> <20091116183116.GR523640@eng.sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091013) Status: RO Content-Length: 9428 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 >>>> >>>> >>> From Garrett.Damore@sun.com Mon Nov 16 11:04:29 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAGJ4RQE021069 for ; Mon, 16 Nov 2009 11:04:28 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id nAGJ4PCH018516 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 16 Nov 2009 19:04:27 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KT700809UBDRI00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 16 Nov 2009 12:04:25 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KT700EF0UB987F0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 16 Nov 2009 12:04:25 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAGJ4LWS026677 for ; Mon, 16 Nov 2009 11:04:21 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KT700I00T9KGR00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 16 Nov 2009 11:04:21 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KT700EA9UAY8H30@fe-sfbay-09.sun.com>; Mon, 16 Nov 2009 11:04:10 -0800 (PST) Date: Mon, 16 Nov 2009 11:04:10 -0800 From: "Garrett D'Amore" Subject: Re: mixerctl improvements [PSARC/2009/626 FastTrack timeout 11/20/2009] In-reply-to: <4B019C1C.5050905@Sun.COM> Sender: Garrett.Damore@sun.com To: Darren J Moffat Cc: Edward Pilatowicz , PSARC-ext@sun.com Reply-to: Garrett.Damore@sun.com Message-id: <4B01A22A.1050707@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200911140245.nAE2jrrU007936@sac.sfbay.sun.com> <4AFE1B1C.7090204@sun.com> <4AFE2280.2030005@sun.com> <20091116183116.GR523640@eng.sun.com> <4B019C1C.5050905@Sun.COM> User-Agent: Thunderbird 2.0.0.23 (X11/20091013) Status: RO Content-Length: 730 Darren J Moffat wrote: > I think audioctl is a better name. However given the nature of > mixerctl I personally would be okay approving incompatible changes to > it for a Minor release binding. > > If it is trivial enough to keep mixerctl around with its current CLI > and introduce audioctl, then great that sounds even better. So what I've done is "revert" mixerctl to its pre-Boomer CLI (modulo some feature differences -- we don't support the old Solaris 10 audio_info structure, and you obviously cannot "disable" the mixer.) The intent here is that mixerctl will go to Obsolete status, and audioctl will be the "new" interface. I'll send out an updated spec later today. - Garrett > > -- > Darren J Moffat From edward.pilatowicz@sun.com Mon Nov 16 13:23:33 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAGLNWZo023795 for ; Mon, 16 Nov 2009 13:23:33 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id nAGLNQEg020396; Mon, 16 Nov 2009 21:23:29 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KT800E0B0R30J00@nwk-avmta-2.sfbay.sun.com>; Mon, 16 Nov 2009 13:23:27 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KT8007IH0R3YY90@nwk-avmta-2.sfbay.sun.com>; Mon, 16 Nov 2009 13:23:27 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id nAGLNO2W661833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Nov 2009 13:23:24 -0800 (PST) Received: (from edp@localhost) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id nAGLNOuJ661830; Mon, 16 Nov 2009 13:23:24 -0800 (PST) Date: Mon, 16 Nov 2009 13:23:23 -0800 From: Edward Pilatowicz Subject: Re: mixerctl improvements [PSARC/2009/626 FastTrack timeout 11/20/2009] In-reply-to: <4B01A1CA.7060308@sun.com> To: "Garrett D'Amore" Cc: Garrett.Damore@sun.com, "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com Message-id: <20091116212323.GW523640@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200911140245.nAE2jrrU007936@sac.sfbay.sun.com> <4AFE1B1C.7090204@sun.com> <4AFE2280.2030005@sun.com> <20091116183116.GR523640@eng.sun.com> <4B01A1CA.7060308@sun.com> X-Authentication-warning: jurassic-x4600.sfbay.sun.com: edp set sender to edward.pilatowicz@sun.com using -f User-Agent: Mutt/1.5.20 (2009-06-14) Status: RO Content-Length: 1829 On Mon, Nov 16, 2009 at 11:02:34AM -0800, Garrett D'Amore wrote: > 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. > ok. but for familiarity sake (since those are common to all OSS based systems), and to facilitate any possible future removal of SADA compatibility, shouldn't we only document the new boomer interfaces? in this case the device path doesn't seem like an API detail. the user as to set AUDIODEV to something. since mixerctl(1) is SADA specific and legacy, it's ok for it to talk about /dev/audio* paths, but shouldn't any newish, non-legacy documentation (say audioctl(1)) and apis always refer to boomer/oss device paths? (note that i'm not talking about the implementation here, just the documentation that end users see.) ed From gdamore@sun.com Mon Nov 16 13:26:04 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAGLQ4hN023811 for ; Mon, 16 Nov 2009 13:26:04 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id nAGLQ3NF046334 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 16 Nov 2009 14:26:04 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KT800E0F0VF6C00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 16 Nov 2009 13:26:03 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KT8007LY0VEYS90@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 16 Nov 2009 13:26:02 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAGLQ2BC012066 for ; Mon, 16 Nov 2009 13:26:02 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KT800G000RP2T00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 16 Nov 2009 13:26:02 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KT8002VB0VDWWF0@fe-sfbay-09.sun.com>; Mon, 16 Nov 2009 13:26:01 -0800 (PST) Date: Mon, 16 Nov 2009 13:26:01 -0800 From: "Garrett D'Amore" Subject: Re: mixerctl improvements [PSARC/2009/626 FastTrack timeout 11/20/2009] In-reply-to: <20091116212323.GW523640@eng.sun.com> Sender: Garrett.Damore@sun.com To: Edward Pilatowicz Cc: Garrett.Damore@sun.com, "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com Message-id: <4B01C369.3070801@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200911140245.nAE2jrrU007936@sac.sfbay.sun.com> <4AFE1B1C.7090204@sun.com> <4AFE2280.2030005@sun.com> <20091116183116.GR523640@eng.sun.com> <4B01A1CA.7060308@sun.com> <20091116212323.GW523640@eng.sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091013) Status: RO Content-Length: 2275 Edward Pilatowicz wrote: > On Mon, Nov 16, 2009 at 11:02:34AM -0800, Garrett D'Amore wrote: > >> 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. >> >> > > ok. but for familiarity sake (since those are common to all OSS based > systems), and to facilitate any possible future removal of SADA > compatibility, shouldn't we only document the new boomer interfaces? in > this case the device path doesn't seem like an API detail. the user as > to set AUDIODEV to something. > > since mixerctl(1) is SADA specific and legacy, it's ok for it to talk > about /dev/audio* paths, but shouldn't any newish, non-legacy > documentation (say audioctl(1)) and apis always refer to boomer/oss > device paths? (note that i'm not talking about the implementation here, > just the documentation that end users see.) > Eventually, this whole AUDIODEV hack will go away. I don't want to create a new environment variable. Users are used to dealing with AUDIODEV, and it works well enough for now. Frankly, were it not for Sun Ray, we wouldn't need AUDIODEV. OSS style applications have no standard environment variable override. - Garrett From gdamore@sun.com Mon Nov 16 13:27:10 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAGLR9lU023825 for ; Mon, 16 Nov 2009 13:27:09 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id nAGLR9BM047205 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 16 Nov 2009 14:27:09 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KT800E090X98Z00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 16 Nov 2009 13:27:09 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KT8007IM0X8YPA0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 16 Nov 2009 13:27:08 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAGLR8KY025843 for ; Mon, 16 Nov 2009 13:27:08 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KT8009000R1JM00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 16 Nov 2009 13:27:08 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KT8008RO0X7VEB0@fe-sfbay-10.sun.com>; Mon, 16 Nov 2009 13:27:08 -0800 (PST) Date: Mon, 16 Nov 2009 13:27:07 -0800 From: "Garrett D'Amore" Subject: Re: mixerctl improvements [PSARC/2009/626 FastTrack timeout 11/20/2009] In-reply-to: <20091116212323.GW523640@eng.sun.com> Sender: Garrett.Damore@sun.com To: Edward Pilatowicz Cc: Garrett.Damore@sun.com, "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com Message-id: <4B01C3AB.2020602@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200911140245.nAE2jrrU007936@sac.sfbay.sun.com> <4AFE1B1C.7090204@sun.com> <4AFE2280.2030005@sun.com> <20091116183116.GR523640@eng.sun.com> <4B01A1CA.7060308@sun.com> <20091116212323.GW523640@eng.sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091013) Status: RO Content-Length: 2122 Edward Pilatowicz wrote: > On Mon, Nov 16, 2009 at 11:02:34AM -0800, Garrett D'Amore wrote: > >> 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. >> >> > > ok. but for familiarity sake (since those are common to all OSS based > systems), and to facilitate any possible future removal of SADA > compatibility, shouldn't we only document the new boomer interfaces? in > this case the device path doesn't seem like an API detail. the user as > to set AUDIODEV to something. > > since mixerctl(1) is SADA specific and legacy, it's ok for it to talk > about /dev/audio* paths, but shouldn't any newish, non-legacy > documentation (say audioctl(1)) and apis always refer to boomer/oss > device paths? (note that i'm not talking about the implementation here, > just the documentation that end users see.) > > ed > One more thought: legacy Sun audio(7I) isn't going away. Its a committed interface. I'm not worried about keeping it around forever. SADA != Sun audio(7I). - Garrett From Garrett.Damore@sun.com Mon Nov 16 16:54:30 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAH0sT1g029627 for ; Mon, 16 Nov 2009 16:54:30 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id nAH0sC5k025307 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 17 Nov 2009 00:54:29 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KT80091LAIRT900@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 16 Nov 2009 16:54:27 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KT800LVBAIPLA90@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 16 Nov 2009 16:54:25 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAH0sPN5000173 for ; Mon, 16 Nov 2009 16:54:25 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KT800900AET5100@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 16 Nov 2009 16:54:25 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KT800D54AIO1V80@fe-sfbay-10.sun.com>; Mon, 16 Nov 2009 16:54:25 -0800 (PST) Date: Mon, 16 Nov 2009 16:54:24 -0800 From: "Garrett D'Amore" Subject: Re: mixerctl improvements [PSARC/2009/626 FastTrack timeout 11/20/2009] In-reply-to: <4B01C3AB.2020602@sun.com> Sender: Garrett.Damore@sun.com To: Edward Pilatowicz Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com Reply-to: Garrett.Damore@sun.com Message-id: <4B01F440.5060505@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200911140245.nAE2jrrU007936@sac.sfbay.sun.com> <4AFE1B1C.7090204@sun.com> <4AFE2280.2030005@sun.com> <20091116183116.GR523640@eng.sun.com> <4B01A1CA.7060308@sun.com> <20091116212323.GW523640@eng.sun.com> <4B01C3AB.2020602@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091013) Status: RO Content-Length: 6909 Okay, so I've done the work on this, and I've decided that given "mixerctl" was formerly Evolving (and unfortunately has name conflicts with similar, yet different, programs from other FOSS), and that it offers zero useful functionality in the Boomer era, that its best to just EOF. So, here is the new spec: 1) EOF mixerctl. 2) Deliver "audioctl" which provides full capabilities, as /usr/bin/audioctl. The following man page has all the latest updates, and accurately reflects the code (other than an undocumented "help" command which only outputs a simple usage summary). Note that the design of the interface is modeled somewhat loosely on dladm, zpool, zoneadm, and other newer commands-that-have-subcommands: User Commands audioctl(1) NAME audioctl - audio mixer control command line application SYNOPSIS audioctl list-devices audioctl show-device [-v] [-d device ] audioctl show-control [-v] [-d device] [control ...] audioctl set-control [-v] [-d device] control value audioctl save-controls [-d device] [-f] file audioctl load-controls [-d device] file DESCRIPTION The audioctl command is used to control various features of the audio mixer and to get information about the audio mixer and the audio device. The audioctl command operates on the following data types: device An audio 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. Any device node associated with an audio device will work as well, such as /dev/sound/0, /dev/dsp1, or /dev/audio. 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: audioctl list-devices List all the audio devices on the system. audioctl show-device [-v] [-d device] Display general information about a device. audioctl show-control [-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. audioctl set-control [-v] [-d device] control value Changes the value of a control to the supplied value. audioctl save-controls [-f] [-d device] file Saves the current state of all mixer control values to the named file. The command will abort safely if the file already exists, unless -f is supplied. audioctl load-controls [-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. 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 audioctl command and its 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-controls and load-controls subcommands is Committed Private. SEE ALSO audioconvert(1), audioplay(1), audiorecord(1), open(2), attributes(5) Garrett D'Amore wrote: > Edward Pilatowicz wrote: >> On Mon, Nov 16, 2009 at 11:02:34AM -0800, Garrett D'Amore wrote: >> >>> 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. >>> >>> >> >> ok. but for familiarity sake (since those are common to all OSS based >> systems), and to facilitate any possible future removal of SADA >> compatibility, shouldn't we only document the new boomer interfaces? in >> this case the device path doesn't seem like an API detail. the user as >> to set AUDIODEV to something. >> >> since mixerctl(1) is SADA specific and legacy, it's ok for it to talk >> about /dev/audio* paths, but shouldn't any newish, non-legacy >> documentation (say audioctl(1)) and apis always refer to boomer/oss >> device paths? (note that i'm not talking about the implementation here, >> just the documentation that end users see.) >> >> ed >> > One more thought: legacy Sun audio(7I) isn't going away. Its a > committed interface. I'm not worried about keeping it around forever. > > SADA != Sun audio(7I). > > - Garrett From cyril.plisko@gmail.com Tue Nov 17 00:16:08 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAH8G77B018962 for ; Tue, 17 Nov 2009 00:16:07 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id nAH8FvmR011745; Tue, 17 Nov 2009 08:16:03 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KT80070RUYQ3H00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 17 Nov 2009 00:16:02 -0800 (PST) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KT8007YOUYP3SD0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 17 Nov 2009 00:16:01 -0800 (PST) Received: from relay43i.sun.com ([192.5.209.74]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nAH83ArB005882; Tue, 17 Nov 2009 08:16:00 +0000 (GMT) Received: from mmp42es.mmp.us.syntegra.com ([160.41.221.11] [160.41.221.11]) by relay43i.sun.com with ESMTP id BT-MMP-6341159; Tue, 17 Nov 2009 08:16:00 +0000 (Z) Received: from relay41i.sun.com (relay41i.sun.com [192.5.209.70]) by mmp42es.mmp.us.syntegra.com with ESMTP id BT-MMP-60212673; Tue, 17 Nov 2009 08:16:00 +0000 (Z) Received: from mail-bw0-f219.google.com ([209.85.218.219] [209.85.218.219]) by relay4i.sun.com with ESMTP id BT-MMP-14367649; Tue, 17 Nov 2009 08:15:59 +0000 (Z) Received: by mail-bw0-f219.google.com with SMTP id 19so7257159bwz.8 for ; Tue, 17 Nov 2009 00:15:09 -0800 (PST) Received: by 10.239.170.35 with SMTP id q35mr310809hbe.150.1258445709190; Tue, 17 Nov 2009 00:15:09 -0800 (PST) Date: Tue, 17 Nov 2009 10:14:49 +0200 From: Cyril Plisko Subject: Re: mixerctl improvements [PSARC/2009/626 FastTrack timeout 11/20/2009] In-reply-to: <4B01F440.5060505@sun.com> Sender: cyril.plisko@gmail.com To: Garrett.Damore@sun.com Cc: Edward Pilatowicz , PSARC-ext@sun.com, "Garrett D'Amore - sun microsystems" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=ubChe3DmL0vgKgNtmqORoZaFnnFE7BpolbUPuKPzCxE=; b=n7LX3+bsDeNhJETh7u1iOLSFPPlRKNqsVkXa/Vl0e/PLvptw575cgxFnyNeBM/9CYi f6z40ap8ar78RqjeFE5V1vmD8cDsMYmC5Chqx5zfQ1QcmNM9zoY8vFGchyd7XBvZyO8N lR5TLC9HGwh7QaaUrmm3VNrFCvlYG8er/U6YE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=lPhWR2zNuo98CJR+qujGnpAi6Q0/JkGsGpPnDVKUzNKKkeCCsbYW82DFn8C3pbjxtH ME/e39Nyvn/6jvrv3hnTRE4uDgjMlbmLAH4bAdI5o4y0ntEUmevUjP0zIUiU54k4Kg7N ZUlt8wcWcwhau+9tZoj6iMKG3T05oiHqWAPW0= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Google-Sender-Auth: 967238760b89d66a X-Antispam: No, score=0.0/5.0, scanned in 0.258sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200911140245.nAE2jrrU007936@sac.sfbay.sun.com> <4AFE1B1C.7090204@sun.com> <4AFE2280.2030005@sun.com> <20091116183116.GR523640@eng.sun.com> <4B01A1CA.7060308@sun.com> <20091116212323.GW523640@eng.sun.com> <4B01C3AB.2020602@sun.com> <4B01F440.5060505@sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sac.sfbay.sun.com id nAH8G77B018962 Status: RO Content-Length: 1058 On Tue, Nov 17, 2009 at 2:54 AM, Garrett D'Amore wrote: > Okay, so I've done the work on this, and I've decided that given "mixerctl" > was formerly Evolving (and unfortunately has name conflicts with similar, > yet different, programs from other FOSS), and that it offers zero useful > functionality in the Boomer era, that its best to just EOF. > Garret, I understand that it cab be somewhat late into the review process, but I rather voice it now, than later. Since there is new utility being created and there are no issues with backward compatibility, - were any thoughts given to the name "audioadm" vs "audioctl" ? It seems that these days Solaris has many *adm tools, as opposed to only a few *ctl. raindrop:~$ ls /usr/man/man1*/*adm.1* | wc -l 66 raindrop:~$ ls /usr/man/man1*/*ctl.1* | wc -l 7 raindrop:~$ Wouldn't it be consistent to stick to this (*adm) pattern ? And before you ask - no, I do not feel strongly about it - just an observation. [Spec materials deleted] -- Regards,        Cyril From Garrett.Damore@sun.com Tue Nov 17 07:18:30 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAHFITAC026397 for ; Tue, 17 Nov 2009 07:18:29 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id nAHFIQnx004373 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 17 Nov 2009 15:18:28 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KT900C2REIRQ200@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 17 Nov 2009 07:18:27 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KT900LR0EIP6O40@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 17 Nov 2009 07:18:25 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAHFIPxg015007 for ; Tue, 17 Nov 2009 07:18:25 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KT900F00EFRM700@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 17 Nov 2009 07:18:25 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KT900K1XEIPYB70@fe-sfbay-09.sun.com>; Tue, 17 Nov 2009 07:18:25 -0800 (PST) Date: Tue, 17 Nov 2009 07:18:24 -0800 From: "Garrett D'Amore" Subject: Re: mixerctl improvements [PSARC/2009/626 FastTrack timeout 11/20/2009] In-reply-to: Sender: Garrett.Damore@sun.com To: Cyril Plisko Cc: Edward Pilatowicz , PSARC-ext@sun.com, "Garrett D'Amore - sun microsystems" Reply-to: Garrett.Damore@sun.com Message-id: <4B02BEC0.9080206@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200911140245.nAE2jrrU007936@sac.sfbay.sun.com> <4AFE1B1C.7090204@sun.com> <4AFE2280.2030005@sun.com> <20091116183116.GR523640@eng.sun.com> <4B01A1CA.7060308@sun.com> <20091116212323.GW523640@eng.sun.com> <4B01C3AB.2020602@sun.com> <4B01F440.5060505@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091013) Status: RO Content-Length: 1406 Cyril Plisko wrote: > On Tue, Nov 17, 2009 at 2:54 AM, Garrett D'Amore wrote: > >> Okay, so I've done the work on this, and I've decided that given "mixerctl" >> was formerly Evolving (and unfortunately has name conflicts with similar, >> yet different, programs from other FOSS), and that it offers zero useful >> functionality in the Boomer era, that its best to just EOF. >> >> > > > Garret, > > I understand that it cab be somewhat late into the review process, > but I rather voice it now, than later. > > Since there is new utility being created and there are no issues > with backward compatibility, - were any thoughts given to the name > "audioadm" vs "audioctl" ? > > It seems that these days Solaris has many *adm tools, as opposed > to only a few *ctl. > > raindrop:~$ ls /usr/man/man1*/*adm.1* | wc -l > 66 > raindrop:~$ ls /usr/man/man1*/*ctl.1* | wc -l > 7 > raindrop:~$ > > Wouldn't it be consistent to stick to this (*adm) pattern ? > > And before you ask - no, I do not feel strongly about it - just an observation. > > [Spec materials deleted] > Its not too late to change this. I actually thought about audioadm. It wasn't clear to me that there was a consistency here; however, I'm more than happy to concede the idea that there are more *adm commands, and if folks prefer, I can trivially change the command now. - Garrett From Joerg.Barfurth@Sun.COM Tue Nov 17 07:37:08 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAHFb8Au026665 for ; Tue, 17 Nov 2009 07:37:08 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nAHFb604029717 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 17 Nov 2009 07:37:08 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KT900G0FFDVFS00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 17 Nov 2009 07:37:07 -0800 (PST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KT900LQDFDR7370@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 17 Nov 2009 07:37:04 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAHFb2Mw023405 for ; Tue, 17 Nov 2009 15:37:02 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KT900600EDDFL00@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 17 Nov 2009 15:36:40 +0000 (GMT) Received: from [10.16.46.243] ([unknown] [10.16.46.243]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KT900DQBFCVXS30@fe-emea-09.sun.com>; Tue, 17 Nov 2009 15:36:31 +0000 (GMT) Date: Tue, 17 Nov 2009 16:36:31 +0100 From: =?ISO-8859-1?Q?J=F6rg_Barfurth?= Subject: Re: mixerctl improvements [PSARC/2009/626 FastTrack timeout 11/20/2009] In-reply-to: <4B02BEC0.9080206@sun.com> Sender: Joerg.Barfurth@Sun.COM To: Garrett.Damore@Sun.COM Cc: Cyril Plisko , PSARC-ext@Sun.COM, "Garrett D'Amore - sun microsystems" Message-id: <4B02C2FF.4000200@sun.com> Organization: Sun Microsystems GmbH MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <200911140245.nAE2jrrU007936@sac.sfbay.sun.com> <4AFE1B1C.7090204@sun.com> <4AFE2280.2030005@sun.com> <20091116183116.GR523640@eng.sun.com> <4B01A1CA.7060308@sun.com> <20091116212323.GW523640@eng.sun.com> <4B01C3AB.2020602@sun.com> <4B01F440.5060505@sun.com> <4B02BEC0.9080206@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090926) Status: RO Content-Length: 2279 Garrett D'Amore schrieb: > Cyril Plisko wrote: >> Since there is new utility being created and there are no issues >> with backward compatibility, - were any thoughts given to the name >> "audioadm" vs "audioctl" ? >> >> It seems that these days Solaris has many *adm tools, as opposed >> to only a few *ctl. >> >> raindrop:~$ ls /usr/man/man1*/*adm.1* | wc -l >> 66 >> raindrop:~$ ls /usr/man/man1*/*ctl.1* | wc -l >> 7 >> raindrop:~$ >> >> Wouldn't it be consistent to stick to this (*adm) pattern ? >> >> And before you ask - no, I do not feel strongly about it - just an >> observation. >> >> [Spec materials deleted] >> > > Its not too late to change this. I actually thought about audioadm. It > wasn't clear to me that there was a consistency here; however, I'm more > than happy to concede the idea that there are more *adm commands, and if > folks prefer, I can trivially change the command now. > I'd expect a **adm command to have the purpose of administering a system service. Typically that would be an administrative (section 1M) command and require some form of privilege. For controlling a running service, in particular if I can do that as a user (section 1) I find **ctl more appropriate. As far as the pattern is concerned: almost all of the **adm commands are in section 1M, and the two that aren't on my system (NIS related admin) probably should be there too. If "audioadm" appears on the system, I'd expect it to provide the capability to create audio devices or control access to them, set global limit volumes or similar administration task with system scope. For changing volume and similar controls on audio devices I happen to own currently, I find "audioctl" or "audiocontrol" a better fit. Just my 2c - Jörg -- Joerg Barfurth Phone: +49 40 23646662 Software Engineer mailto:joerg.barfurth@sun.com Desktop Technology Thin Client Software http://www.sun.com/software/sunray/ Sun Microsystems GmbH http://www.sun.com/software/javadesktopsystem/ Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering From Garrett.Damore@sun.com Tue Nov 17 07:40:35 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAHFeZfX026727 for ; Tue, 17 Nov 2009 07:40:35 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nAHFeWBT009557 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 17 Nov 2009 07:40:35 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KT900107FJM9800@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 17 Nov 2009 08:40:34 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KT900D6VFJLAZC0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 17 Nov 2009 08:40:34 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAHFeXs8016616 for ; Tue, 17 Nov 2009 07:40:33 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KT900J00FEWFP00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 17 Nov 2009 07:40:33 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KT900KG8FJLYBF0@fe-sfbay-09.sun.com>; Tue, 17 Nov 2009 07:40:33 -0800 (PST) Date: Tue, 17 Nov 2009 07:40:32 -0800 From: "Garrett D'Amore" Subject: Re: mixerctl improvements [PSARC/2009/626 FastTrack timeout 11/20/2009] In-reply-to: <4B02C2FF.4000200@sun.com> Sender: Garrett.Damore@sun.com To: =?ISO-8859-1?Q?J=F6rg_Barfurth?= Cc: Cyril Plisko , PSARC-ext@sun.com, "Garrett D'Amore - sun microsystems" Reply-to: Garrett.Damore@sun.com Message-id: <4B02C3F0.1030008@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <200911140245.nAE2jrrU007936@sac.sfbay.sun.com> <4AFE1B1C.7090204@sun.com> <4AFE2280.2030005@sun.com> <20091116183116.GR523640@eng.sun.com> <4B01A1CA.7060308@sun.com> <20091116212323.GW523640@eng.sun.com> <4B01C3AB.2020602@sun.com> <4B01F440.5060505@sun.com> <4B02BEC0.9080206@sun.com> <4B02C2FF.4000200@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091013) Status: RO Content-Length: 2468 Jörg Barfurth wrote: > Garrett D'Amore schrieb: >> Cyril Plisko wrote: > >>> Since there is new utility being created and there are no issues >>> with backward compatibility, - were any thoughts given to the name >>> "audioadm" vs "audioctl" ? >>> >>> It seems that these days Solaris has many *adm tools, as opposed >>> to only a few *ctl. >>> >>> raindrop:~$ ls /usr/man/man1*/*adm.1* | wc -l >>> 66 >>> raindrop:~$ ls /usr/man/man1*/*ctl.1* | wc -l >>> 7 >>> raindrop:~$ >>> >>> Wouldn't it be consistent to stick to this (*adm) pattern ? >>> >>> And before you ask - no, I do not feel strongly about it - just an >>> observation. >>> >>> [Spec materials deleted] >>> >> >> Its not too late to change this. I actually thought about audioadm. >> It wasn't clear to me that there was a consistency here; however, I'm >> more than happy to concede the idea that there are more *adm >> commands, and if folks prefer, I can trivially change the command now. >> > > I'd expect a **adm command to have the purpose of administering a > system service. Typically that would be an administrative (section 1M) > command and require some form of privilege. > > For controlling a running service, in particular if I can do that as a > user (section 1) I find **ctl more appropriate. > > As far as the pattern is concerned: almost all of the **adm commands > are in section 1M, and the two that aren't on my system (NIS related > admin) probably should be there too. > > If "audioadm" appears on the system, I'd expect it to provide the > capability to create audio devices or control access to them, set > global limit volumes or similar administration task with system scope. > > For changing volume and similar controls on audio devices I happen to > own currently, I find "audioctl" or "audiocontrol" a better fit. At present, this tool is used just by end-users to adjust personal preferences. However, in the future it might be used to do some more sophisticated things ... like configuring hotplug policies, etc. Some settings could arguably said to be administration... such as the configuration of jack retasking. (Is defining the purpose of jacks an administrator or an end-user task? Its not clear to me.) At the end of the day, I don't have a strong preference one way or the other for the name. I think *ctl mostly evolved out of mixerctl. As long is it isn't "audiotool". :-p - Garrett > > Just my 2c > > - Jörg > From Sebastien.Roy@sun.com Wed Nov 18 09:04:12 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAIH4Cni013052 for ; Wed, 18 Nov 2009 09:04:12 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nAIH4ACQ017814 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 18 Nov 2009 09:04:12 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KTB00163E2ZV900@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Nov 2009 09:04:11 -0800 (PST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KTB0084IE2YJW70@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Nov 2009 09:04:11 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nAIH4AaD013623 for ; Wed, 18 Nov 2009 17:04:10 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KTB00500C16BZ00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Nov 2009 10:04:10 -0700 (MST) Received: from [129.148.174.103] ([unknown] [129.148.174.103]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTB00HVEE2E2LD0@mail-amer.sun.com>; Wed, 18 Nov 2009 10:03:51 -0700 (MST) Date: Wed, 18 Nov 2009 12:01:11 -0500 From: Sebastien Roy Subject: Re: mixerctl improvements [PSARC/2009/626 FastTrack timeout 11/20/2009] In-reply-to: <4B01F440.5060505@sun.com> Sender: Sebastien.Roy@sun.com To: Garrett.Damore@sun.com Cc: Edward Pilatowicz , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com Message-id: <1258563671.4046.80.camel@strat> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200911140245.nAE2jrrU007936@sac.sfbay.sun.com> <4AFE1B1C.7090204@sun.com> <4AFE2280.2030005@sun.com> <20091116183116.GR523640@eng.sun.com> <4B01A1CA.7060308@sun.com> <20091116212323.GW523640@eng.sun.com> <4B01C3AB.2020602@sun.com> <4B01F440.5060505@sun.com> Status: RO Content-Length: 1267 Some nits on the CLI: On Mon, 2009-11-16 at 16:54 -0800, Garrett D'Amore wrote: > audioctl list-devices > > audioctl show-device [-v] [-d device ] > > audioctl show-control [-v] [-d device] [control ...] I find it odd that the object specifier for show-device requires an option, but that show-control does not. It seems that all of the subcommands operate on a device, so it would be natural to simply specify that device as the final (perhaps optional) argument to each subcommand (without a -d), and require options for everything else. For example: audioctl list-devices audioctl show-device [-v] [device ] audioctl show-control [-v] [-c control[,...]] [device] audioctl set-control [-v] -c control=value[,...] device audioctl save-controls -f file [device] audioctl load-controls -f file [device] The use of plural objects in subcommands is odd to me as well, but that's not a big deal. > audioctl set-control [-v] [-d device] control value > What would a -v option print in a set operation? Also, the syntax proposed seems awkward. Why not use something more common such as is parsed by getsubopt() like (for example): -c =[,=...] Is the device really optional here? -Seb From Garrett.Damore@sun.com Wed Nov 18 09:31:54 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAIHVrrd014997 for ; Wed, 18 Nov 2009 09:31:53 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id nAIHVbFt014656 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 18 Nov 2009 17:31:52 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KTB00037FD49V00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Nov 2009 09:31:52 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KTB00HGDFCXJR90@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Nov 2009 09:31:45 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAIHVjqC000394 for ; Wed, 18 Nov 2009 09:31:45 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KTB00A00DJA7Z00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Nov 2009 09:31:45 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTB00AAFFCW1R30@fe-sfbay-10.sun.com>; Wed, 18 Nov 2009 09:31:44 -0800 (PST) Date: Wed, 18 Nov 2009 09:31:44 -0800 From: "Garrett D'Amore" Subject: Re: mixerctl improvements [PSARC/2009/626 FastTrack timeout 11/20/2009] In-reply-to: <1258563671.4046.80.camel@strat> Sender: Garrett.Damore@sun.com To: Sebastien Roy Cc: Edward Pilatowicz , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com Reply-to: Garrett.Damore@sun.com Message-id: <4B042F80.6000609@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200911140245.nAE2jrrU007936@sac.sfbay.sun.com> <4AFE1B1C.7090204@sun.com> <4AFE2280.2030005@sun.com> <20091116183116.GR523640@eng.sun.com> <4B01A1CA.7060308@sun.com> <20091116212323.GW523640@eng.sun.com> <4B01C3AB.2020602@sun.com> <4B01F440.5060505@sun.com> <1258563671.4046.80.camel@strat> User-Agent: Thunderbird 2.0.0.23 (X11/20091013) Status: RO Content-Length: 2517 Sebastien Roy wrote: > Some nits on the CLI: > > On Mon, 2009-11-16 at 16:54 -0800, Garrett D'Amore wrote: > >> audioctl list-devices >> >> audioctl show-device [-v] [-d device ] >> >> audioctl show-control [-v] [-d device] [control ...] >> > > I find it odd that the object specifier for show-device requires an > option, but that show-control does not. It seems that all of the > subcommands operate on a device, so it would be natural to simply > specify that device as the final (perhaps optional) argument to each > subcommand (without a -d), and require options for everything else. For > example: > I don't agree. -d will probably not be used for the vast majority of cases. Whereas the control field really does. The syntax I've proposed is actually the result of me working with the existing commands day in and day out, and playing with variants because I've been so annoyed at the existing syntax. > audioctl list-devices > > audioctl show-device [-v] [device ] > > audioctl show-control [-v] [-c control[,...]] [device] > > audioctl set-control [-v] -c control=value[,...] device > > audioctl save-controls -f file [device] > > audioctl load-controls -f file [device] > > The use of plural objects in subcommands is odd to me as well, but > that's not a big deal. > save-controls and load-controls save *all* controls to the file. > >> audioctl set-control [-v] [-d device] control value >> >> > > What would a -v option print in a set operation? > It shows the effect of the operation, rather than operating silently. audiots-x86/pepper> ./audioctl set-control -v beep 100 audiohd#0: 'beep' set to '100' Without the -v, it is silent. > Also, the syntax proposed seems awkward. Why not use something more > common such as is parsed by getsubopt() like (for example): > > -c =[,=...] > Again, I've played with it. The old syntax was "-c -w ", and didn't use a subcommand. It was found to be awkward in practice. The new syntax is actually more friendly: audioctl set-control volume 50 No special getopt arguments, and the command says exactly what it does. > Is the device really optional here? > The device really is optional. If you only have one device (or a sensible default), then you don't need to specify which one it applies to. So while I hear what you're saying about the syntax, I'm disagreeing with your suggestions. - Garrett From sebastien.roy@sun.com Wed Nov 18 10:53:02 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAIIr1qC020410 for ; Wed, 18 Nov 2009 10:53:02 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id nAIIqpk4021388 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 18 Nov 2009 18:53:01 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KTB0051BJ4B3200@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Nov 2009 10:52:59 -0800 (PST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KTB004WAJ4ASK20@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Nov 2009 10:52:58 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nAIIqvVE012389 for ; Wed, 18 Nov 2009 18:52:57 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KTB00L00IFR7000@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Nov 2009 11:52:57 -0700 (MST) Received: from [129.148.174.103] ([unknown] [129.148.174.103]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTB009T2J3ZUN50@mail-amer.sun.com>; Wed, 18 Nov 2009 11:52:48 -0700 (MST) Date: Wed, 18 Nov 2009 13:50:08 -0500 From: Sebastien Roy Subject: Re: mixerctl improvements [PSARC/2009/626 FastTrack timeout 11/20/2009] In-reply-to: <4B042F80.6000609@sun.com> Sender: sebastien.roy@sun.com To: Garrett.Damore@sun.com Cc: Edward Pilatowicz , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com Message-id: <1258570208.4046.206.camel@strat> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200911140245.nAE2jrrU007936@sac.sfbay.sun.com> <4AFE1B1C.7090204@sun.com> <4AFE2280.2030005@sun.com> <20091116183116.GR523640@eng.sun.com> <4B01A1CA.7060308@sun.com> <20091116212323.GW523640@eng.sun.com> <4B01C3AB.2020602@sun.com> <4B01F440.5060505@sun.com> <1258563671.4046.80.camel@strat> <4B042F80.6000609@sun.com> Status: RO Content-Length: 282 On Wed, 2009-11-18 at 09:31 -0800, Garrett D'Amore wrote: > So while I hear what you're saying about the syntax, I'm disagreeing > with your suggestions. I see. I'm fine with the architecture of the case at a high-level, so I gave the case a +1 during the meeting today. -Seb From Garrett.Damore@Sun.COM Wed Nov 18 22:15:41 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAJ6FedH011709 for ; Wed, 18 Nov 2009 22:15:41 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id nAJ6FaLc011080 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 19 Nov 2009 06:15:40 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KTC00E0DEQ3O100@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Nov 2009 23:15:39 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KTC000GLEQ3ST80@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Nov 2009 23:15:39 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAJ6FdC4029944 for ; Wed, 18 Nov 2009 22:15:39 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KTC00600EM40N00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Nov 2009 22:15:39 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTC00MA0EQ2RJ20@fe-sfbay-09.sun.com>; Wed, 18 Nov 2009 22:15:39 -0800 (PST) Date: Wed, 18 Nov 2009 22:15:38 -0800 From: "Garrett D'Amore" Subject: Re: mixerctl improvements [PSARC/2009/626 FastTrack timeout 11/20/2009] In-reply-to: <1258570208.4046.206.camel@strat> Sender: Garrett.Damore@Sun.COM To: Sebastien Roy Cc: Edward Pilatowicz , "Garrett D'Amore - sun microsystems" , PSARC-ext@Sun.COM Reply-to: Garrett.Damore@Sun.COM Message-id: <4B04E28A.5000100@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200911140245.nAE2jrrU007936@sac.sfbay.sun.com> <4AFE1B1C.7090204@sun.com> <4AFE2280.2030005@sun.com> <20091116183116.GR523640@eng.sun.com> <4B01A1CA.7060308@sun.com> <20091116212323.GW523640@eng.sun.com> <4B01C3AB.2020602@sun.com> <4B01F440.5060505@sun.com> <1258563671.4046.80.camel@strat> <4B042F80.6000609@sun.com> <1258570208.4046.206.camel@strat> User-Agent: Thunderbird 2.0.0.23 (X11/20091013) Status: RO Content-Length: 442 Sebastien Roy wrote: > On Wed, 2009-11-18 at 09:31 -0800, Garrett D'Amore wrote: > >> So while I hear what you're saying about the syntax, I'm disagreeing >> with your suggestions. >> > > I see. I'm fine with the architecture of the case at a high-level, so I > gave the case a +1 during the meeting today. > > -Seb > > > This case was approved at PSARC today; consensus was to leave the new command "audioctl". - Garrett