* [alsa-utils] alsaucm should come with a man page @ 2016-07-27 9:48 Antonio Ospite 2016-08-03 15:57 ` Takashi Iwai 0 siblings, 1 reply; 10+ messages in thread From: Antonio Ospite @ 2016-07-27 9:48 UTC (permalink / raw) To: alsa-devel; +Cc: Pierre-Louis Bossart, Stefan Schmidt, Justin Xu, Liam Girdwood Hi, I used alsaucm to test mixer use cases for an Intel Baytrail tablet, I wanted to use bare alsa before bringing pulseaudio in, and it took some time to get my head around it. The output from the "alsaucm --help" is too terse, I had to look at the alsa-lib code[1] to see the possible IDENTIFIERs, and even then it was not clear to me that some operations, like for instance "list _devices", can only work after setting a _verb in the same _execution_, for instance this sequence doesn't work: # alsaucm -c bytcr-rt5640 set _verb HiFi # alsaucm -c bytcr-rt5640 list _devices But this command does: # alsaucm -c bytcr-rt5640 -b - <<EOM set _verb HiFi list _devces EOM Now that I know something more it makes sense: UCM just operates on mixer settings, it does not have its own external state. However, my point is that a man page explaining these things can make the life easier to new users. It would be better if alsa/UCM developers wrote the man page, but if no one steps up I guess I could draft a first version myself. Thanks, Antonio [1] http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=include/use-case.h -- Antonio Ospite http://ao2.it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [alsa-utils] alsaucm should come with a man page 2016-07-27 9:48 [alsa-utils] alsaucm should come with a man page Antonio Ospite @ 2016-08-03 15:57 ` Takashi Iwai 2016-08-08 16:30 ` Antonio Ospite 0 siblings, 1 reply; 10+ messages in thread From: Takashi Iwai @ 2016-08-03 15:57 UTC (permalink / raw) To: Antonio Ospite Cc: alsa-devel, Stefan Schmidt, Liam Girdwood, Pierre-Louis Bossart, Justin Xu On Wed, 27 Jul 2016 11:48:28 +0200, Antonio Ospite wrote: > > Hi, > > I used alsaucm to test mixer use cases for an Intel Baytrail tablet, I > wanted to use bare alsa before bringing pulseaudio in, and it took some > time to get my head around it. > > The output from the "alsaucm --help" is too terse, I had to look at the > alsa-lib code[1] to see the possible IDENTIFIERs, and even then it was > not clear to me that some operations, like for instance "list _devices", > can only work after setting a _verb in the same _execution_, for > instance this sequence doesn't work: > > # alsaucm -c bytcr-rt5640 set _verb HiFi > # alsaucm -c bytcr-rt5640 list _devices > > But this command does: > > # alsaucm -c bytcr-rt5640 -b - <<EOM > set _verb HiFi > list _devces > EOM > > Now that I know something more it makes sense: UCM just operates on > mixer settings, it does not have its own external state. > > However, my point is that a man page explaining these things can make > the life easier to new users. > > It would be better if alsa/UCM developers wrote the man page, but if no > one steps up I guess I could draft a first version myself. Go ahead, please post your draft version. That's already helpful. thanks, Takashi ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [alsa-utils] alsaucm should come with a man page 2016-08-03 15:57 ` Takashi Iwai @ 2016-08-08 16:30 ` Antonio Ospite 2016-09-23 16:37 ` Antonio Ospite 0 siblings, 1 reply; 10+ messages in thread From: Antonio Ospite @ 2016-08-08 16:30 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel, Justin Xu, Pierre-Louis Bossart, Liam Girdwood On Wed, 03 Aug 2016 17:57:49 +0200 Takashi Iwai <tiwai@suse.de> wrote: > On Wed, 27 Jul 2016 11:48:28 +0200, > Antonio Ospite wrote: > > > > Hi, > > > > I used alsaucm to test mixer use cases for an Intel Baytrail tablet, I > > wanted to use bare alsa before bringing pulseaudio in, and it took some > > time to get my head around it. [...] > > However, my point is that a man page explaining these things can make > > the life easier to new users. > > > > It would be better if alsa/UCM developers wrote the man page, but if no > > one steps up I guess I could draft a first version myself. > > Go ahead, please post your draft version. That's already helpful. > OK, I will. The first version will be in a readable text format (maybe asciidoc), this makes writing and reviewing the content a lot easier. Then, if depending on an external tool to generate the man page automatically is not acceptable for alsa-utils, I will format the approved content manually following the style used in the man pages of the other alsa programs. Thanks, Antonio -- Antonio Ospite http://ao2.it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [alsa-utils] alsaucm should come with a man page 2016-08-08 16:30 ` Antonio Ospite @ 2016-09-23 16:37 ` Antonio Ospite 2016-09-29 8:00 ` Takashi Iwai 0 siblings, 1 reply; 10+ messages in thread From: Antonio Ospite @ 2016-09-23 16:37 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel, Liam Girdwood, Pierre-Louis Bossart, Justin Xu On Mon, 8 Aug 2016 18:30:41 +0200 Antonio Ospite <ao2@ao2.it> wrote: > On Wed, 03 Aug 2016 17:57:49 +0200 > Takashi Iwai <tiwai@suse.de> wrote: > [...] > > Go ahead, please post your draft version. That's already helpful. > > > > OK, I will. > > The first version will be in a readable text format (maybe asciidoc), > this makes writing and reviewing the content a lot easier. [...] Hi, I am inlining below a man page written in reStructuredText, I saw that other kernel subsystem are using this format. The document can be converted to a unix man page with the rst2man command available in the python3-docutils package (on Debian systems). BTW, there is also a rst2html which can be handy. Let's just review the content for now, but let me also know if you want the groff man page in the final patch or if shipping this .rst and generating the man page at compile time is OK. Ciao, Antonio ========= alsaucm ========= --------------------- ALSA Use Case Manager --------------------- :Author: Antonio Ospite <ao2@ao2.it> :Date: 2016-09-22 :Copyright: GPLv2+ :Manual section: 1 :Manual group: General Commands Manual SYNOPSIS ======== *alsaucm* <options> [command] DESCRIPTION =========== alsaucm (ALSA Use Case Manager) is a program to use the ALSA `Use Case Interface`_ from the command line. On complex sound cards, setting up audio routes is not trivial and mixer settings can conflict one another preventing the audio card to work at all. The ALSA Use Case Manager is a mechanism for controlling complex audio hardware establishing a relationship between hardware configurations and meaningful use cases that the end-user can relate with. The use case manager can also be used to switch between use cases when necessary, in a consistent way. At a lower level, the use case manager works by configuring the sound card ALSA kcontrols to change the hardware digital and analog audio routing to match the requested device use case. The use case manager kcontrol configurations are stored in easy to modify text files. An audio use case can be defined by a **verb** and **device** parameter. The verb describes the use case action i.e. a phone call, listening to music, recording a conversation etc. The device describes the physical audio capture and playback hardware i.e. headphones, phone handset, bluetooth headset, etc. OPTIONS ======= Available options: **-h**, **--help** this help **-c**, **--card** `NAME` open card NAME **-i**, **--interactive** interactive mode **-b**, **--batch** `FILE` batch mode (use ``'-'`` for the stdin input) **-n**, **--no-open** do not open first card found Available commands: ``open`` `NAME` open card NAME. valid names are sound card names as listed in ``/usr/share/alsa/ucm``. ``reset`` reset sound card to default state. ``reload`` reload configuration. ``listcards`` list available cards. ``list`` `IDENTIFIER` list command, for items returning two entries (value+comment). the value of the `IDENTIFIER` argument can can be: - ``_verbs`` - get verb list (in pair verb+comment) - ``_devices[/{verb}]`` - get list of supported devices (in pair device+comment) - ``_modifiers[/{verb}]`` - get list of supported modifiers (in pair modifier+comment) The forms without the trailing ``/{verb}`` are valid only after a specific verb has been set. ``list1`` `IDENTIFIER` list command, for lists returning one item per entry. the value of the `IDENTIFIER` argument can vary depending on the context, it can be: - ``TQ[/{verb}]`` - get list of Tone Quality identifiers - ``_enadevs`` - get list of enabled devices - ``_enamods`` - get list of enabled modifiers - ``_supporteddevs/{modifier}|{device}[/{verb}]`` - list of supported devices - ``_conflictingdevs/{modifier}|{device}[/{verb}]`` - list of conflicting devices ``get`` `IDENTIFIER` get string value. the value of the `IDENTIFIER` argument can can be: - ``_verb`` - return current verb - ``[=]{NAME}[/[{modifier}|{/device}][/{verb}]]`` (For valid NAMEs look at the ALSA `Use Case Interface`_) ``geti`` `IDENTIFIER` get integer value. the value of the `IDENTIFIER` argument can can be: - ``_devstatus/{device}`` - ``_modtstaus/{device}`` ``set`` `IDENTIFIER` `VALUE` set string value The value of the `IDENTIFIER` argument can can be: - ``_verb`` - set the verb to `VALUE` - ``_enadev`` - enable the device specified by `VALUE` - ``_disdev`` - disable the device specified by `VALUE` - ``_swdev/{old_device}`` - switche device: - disable `old_device` and then enable the device specified by `VALUE` - if no device was enabled just return - ``_enamod`` - enable the modifier specified by `VALUE` - ``_dismod`` - disable the modifier specified by `VALUE` - ``_swmod/{old_modifier}`` - switch modifier: - disable `old_modifier` and then enable the modifier specified by `VALUE` - if no modifier was enabled just return Note that the identifiers referring to devices and modifiers are valid only after setting a verb. ``h``, ``help`` help ``q``, ``quit`` quit FILES ===== The master use case files for each supported sound card are in ``/usr/share/alsa/ucm``. For example, the master use case file for the `Pandaboard` card is in ``/usr/share/alsa/ucm/PandaBoard/PandaBoard.conf``, this file lists all the supported use cases, e.g. :: SectionUseCase."HiFi" { File "hifi" Comment "Play HiFi quality Music." } ... Each use case defines a _verb, which is described in the file specified in the ``File`` directive, like above. The ``HiFi`` verb above is described in ``/usr/share/alsa/ucm/PandaBoard/hifi``. For more details on the syntax of UCM files, see the alsa-lib source code: http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=src/ucm/parser.c EXAMPLES OF USE =============== Some commands, like for instance ``list _devices``, can only work after setting a ``_verb`` in the **same execution**, for instance this sequence doesn't work: :: # alsaucm -c bytcr-rt5640 set _verb HiFi # alsaucm -c bytcr-rt5640 list _devices However this command does: :: # alsaucm -n -b - <<EOM open bytcr-rt5640 set _verb HiFi list _devices EOM An example of setting the `Speaker` device for the `HiFi` verb of the `bytcr-rt5640` card: :: # alsaucm -n -b - <<EOM open bytcr-rt5640 reset set _verb HiFi set _enadev Speaker EOM SEE ALSO ======== * Use Case Interface: http://www.alsa-project.org/alsa-doc/alsa-lib/group__ucm.html .. _Use Case Interface: http://www.alsa-project.org/alsa-doc/alsa-lib/group__ucm.html BUGS ==== None known. -- Antonio Ospite https://ao2.it https://twitter.com/ao2it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [alsa-utils] alsaucm should come with a man page 2016-09-23 16:37 ` Antonio Ospite @ 2016-09-29 8:00 ` Takashi Iwai 2016-10-26 17:01 ` Antonio Ospite 0 siblings, 1 reply; 10+ messages in thread From: Takashi Iwai @ 2016-09-29 8:00 UTC (permalink / raw) To: Antonio Ospite; +Cc: alsa-devel, Liam Girdwood, Pierre-Louis Bossart, Justin Xu On Fri, 23 Sep 2016 18:37:10 +0200, Antonio Ospite wrote: > > On Mon, 8 Aug 2016 18:30:41 +0200 > Antonio Ospite <ao2@ao2.it> wrote: > > > On Wed, 03 Aug 2016 17:57:49 +0200 > > Takashi Iwai <tiwai@suse.de> wrote: > > > [...] > > > Go ahead, please post your draft version. That's already helpful. > > > > > > > OK, I will. > > > > The first version will be in a readable text format (maybe asciidoc), > > this makes writing and reviewing the content a lot easier. > [...] > > Hi, I am inlining below a man page written in reStructuredText, I saw > that other kernel subsystem are using this format. > > The document can be converted to a unix man page with the rst2man > command available in the python3-docutils package (on Debian systems). > BTW, there is also a rst2html which can be handy. Yes, ReST looks like a good choice for now. > Let's just review the content for now, but let me also know if you want > the groff man page in the final patch or if shipping this .rst and > generating the man page at compile time is OK. Liam, could you review the content? thanks, Takashi > > Ciao, > Antonio > > ========= > alsaucm > ========= > > --------------------- > ALSA Use Case Manager > --------------------- > > :Author: Antonio Ospite <ao2@ao2.it> > :Date: 2016-09-22 > :Copyright: GPLv2+ > :Manual section: 1 > :Manual group: General Commands Manual > > SYNOPSIS > ======== > > *alsaucm* <options> [command] > > DESCRIPTION > =========== > > alsaucm (ALSA Use Case Manager) is a program to use the ALSA `Use Case > Interface`_ from the command line. > > On complex sound cards, setting up audio routes is not trivial and mixer > settings can conflict one another preventing the audio card to work at all. > > The ALSA Use Case Manager is a mechanism for controlling complex audio > hardware establishing a relationship between hardware configurations and > meaningful use cases that the end-user can relate with. > > The use case manager can also be used to switch between use cases when > necessary, in a consistent way. > > At a lower level, the use case manager works by configuring the sound card > ALSA kcontrols to change the hardware digital and analog audio routing to > match the requested device use case. > > The use case manager kcontrol configurations are stored in easy to modify text > files. An audio use case can be defined by a **verb** and **device** parameter. > > The verb describes the use case action i.e. a phone call, listening to music, > recording a conversation etc. The device describes the physical audio capture > and playback hardware i.e. headphones, phone handset, bluetooth headset, etc. > > > OPTIONS > ======= > > Available options: > > **-h**, **--help** > this help > > **-c**, **--card** `NAME` > open card NAME > > **-i**, **--interactive** > interactive mode > > **-b**, **--batch** `FILE` > batch mode (use ``'-'`` for the stdin input) > > **-n**, **--no-open** > do not open first card found > > > Available commands: > > ``open`` `NAME` > open card NAME. > > valid names are sound card names as listed in ``/usr/share/alsa/ucm``. > > ``reset`` > reset sound card to default state. > > ``reload`` > reload configuration. > > ``listcards`` > list available cards. > > ``list`` `IDENTIFIER` > list command, for items returning two entries (value+comment). > > the value of the `IDENTIFIER` argument can can be: > > - ``_verbs`` - get verb list (in pair verb+comment) > - ``_devices[/{verb}]`` - get list of supported devices (in pair device+comment) > - ``_modifiers[/{verb}]`` - get list of supported modifiers (in pair modifier+comment) > > The forms without the trailing ``/{verb}`` are valid only after a specific > verb has been set. > > ``list1`` `IDENTIFIER` > list command, for lists returning one item per entry. > > the value of the `IDENTIFIER` argument can vary depending on the context, > it can be: > > - ``TQ[/{verb}]`` - get list of Tone Quality identifiers > - ``_enadevs`` - get list of enabled devices > - ``_enamods`` - get list of enabled modifiers > - ``_supporteddevs/{modifier}|{device}[/{verb}]`` - list of supported devices > - ``_conflictingdevs/{modifier}|{device}[/{verb}]`` - list of conflicting devices > > ``get`` `IDENTIFIER` > get string value. > > the value of the `IDENTIFIER` argument can can be: > > - ``_verb`` - return current verb > - ``[=]{NAME}[/[{modifier}|{/device}][/{verb}]]`` (For valid NAMEs look at the > ALSA `Use Case Interface`_) > > > ``geti`` `IDENTIFIER` > get integer value. > > the value of the `IDENTIFIER` argument can can be: > > - ``_devstatus/{device}`` > - ``_modtstaus/{device}`` > > ``set`` `IDENTIFIER` `VALUE` > set string value > > The value of the `IDENTIFIER` argument can can be: > > - ``_verb`` - set the verb to `VALUE` > - ``_enadev`` - enable the device specified by `VALUE` > - ``_disdev`` - disable the device specified by `VALUE` > - ``_swdev/{old_device}`` - switche device: > > - disable `old_device` and then enable the device specified by > `VALUE` > - if no device was enabled just return > > - ``_enamod`` - enable the modifier specified by `VALUE` > - ``_dismod`` - disable the modifier specified by `VALUE` > - ``_swmod/{old_modifier}`` - switch modifier: > > - disable `old_modifier` and then enable the modifier specified by > `VALUE` > - if no modifier was enabled just return > > Note that the identifiers referring to devices and modifiers are valid > only after setting a verb. > > ``h``, ``help`` > help > > ``q``, ``quit`` > quit > > > FILES > ===== > > The master use case files for each supported sound card are in ``/usr/share/alsa/ucm``. > > For example, the master use case file for the `Pandaboard` card is in > ``/usr/share/alsa/ucm/PandaBoard/PandaBoard.conf``, this file lists all the > supported use cases, e.g. > > :: > > SectionUseCase."HiFi" { > File "hifi" > Comment "Play HiFi quality Music." > } > ... > > > Each use case defines a _verb, which is described in the file specified in > the ``File`` directive, like above. > > The ``HiFi`` verb above is described in > ``/usr/share/alsa/ucm/PandaBoard/hifi``. > > For more details on the syntax of UCM files, see the alsa-lib source code: > http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=src/ucm/parser.c > > > EXAMPLES OF USE > =============== > > Some commands, like for instance ``list _devices``, > can only work after setting a ``_verb`` in the **same execution**, for > instance this sequence doesn't work: > > :: > > # alsaucm -c bytcr-rt5640 set _verb HiFi > # alsaucm -c bytcr-rt5640 list _devices > > > However this command does: > > :: > > # alsaucm -n -b - <<EOM > open bytcr-rt5640 > set _verb HiFi > list _devices > EOM > > > An example of setting the `Speaker` device for the `HiFi` verb of the > `bytcr-rt5640` card: > > :: > > # alsaucm -n -b - <<EOM > open bytcr-rt5640 > reset > set _verb HiFi > set _enadev Speaker > EOM > > > > SEE ALSO > ======== > > * Use Case Interface: http://www.alsa-project.org/alsa-doc/alsa-lib/group__ucm.html > > .. _Use Case Interface: http://www.alsa-project.org/alsa-doc/alsa-lib/group__ucm.html > > BUGS > ==== > > None known. > > > -- > Antonio Ospite > https://ao2.it > https://twitter.com/ao2it > > A: Because it messes up the order in which people normally read text. > See http://en.wikipedia.org/wiki/Posting_style > Q: Why is top-posting such a bad thing? > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [alsa-utils] alsaucm should come with a man page 2016-09-29 8:00 ` Takashi Iwai @ 2016-10-26 17:01 ` Antonio Ospite 2016-12-02 12:11 ` Antonio Ospite 0 siblings, 1 reply; 10+ messages in thread From: Antonio Ospite @ 2016-10-26 17:01 UTC (permalink / raw) To: Takashi Iwai Cc: Liam Girdwood, alsa-devel, Pierre-Louis Bossart, Liam Girdwood On Thu, 29 Sep 2016 10:00:48 +0200 Takashi Iwai <tiwai@suse.de> wrote: > On Fri, 23 Sep 2016 18:37:10 +0200, > Antonio Ospite wrote: > > > > On Mon, 8 Aug 2016 18:30:41 +0200 > > Antonio Ospite <ao2@ao2.it> wrote: > > > > > On Wed, 03 Aug 2016 17:57:49 +0200 > > > Takashi Iwai <tiwai@suse.de> wrote: > > > > > [...] > > > > Go ahead, please post your draft version. That's already helpful. > > > > > > > > > > OK, I will. > > > > > > The first version will be in a readable text format (maybe asciidoc), > > > this makes writing and reviewing the content a lot easier. > > [...] > > > > Hi, I am inlining below a man page written in reStructuredText, I saw > > that other kernel subsystems are using this format. > > > > The document can be converted to a unix man page with the rst2man > > command available in the python3-docutils package (on Debian systems). > > BTW, there is also a rst2html which can be handy. > > Yes, ReST looks like a good choice for now. > > > Let's just review the content for now, but let me also know if you want > > the groff man page in the final patch or if shipping this .rst and > > generating the man page at compile time is OK. > > Liam, could you review the content? > Ping, plus adding Liam's Intel address just in case. Thanks, Antonio > > ========= > > alsaucm > > ========= > > > > --------------------- > > ALSA Use Case Manager > > --------------------- > > > > :Author: Antonio Ospite <ao2@ao2.it> > > :Date: 2016-09-22 > > :Copyright: GPLv2+ > > :Manual section: 1 > > :Manual group: General Commands Manual > > > > SYNOPSIS > > ======== > > > > *alsaucm* <options> [command] > > > > DESCRIPTION > > =========== > > > > alsaucm (ALSA Use Case Manager) is a program to use the ALSA `Use Case > > Interface`_ from the command line. > > > > On complex sound cards, setting up audio routes is not trivial and mixer > > settings can conflict one another preventing the audio card to work at all. > > > > The ALSA Use Case Manager is a mechanism for controlling complex audio > > hardware establishing a relationship between hardware configurations and > > meaningful use cases that the end-user can relate with. > > > > The use case manager can also be used to switch between use cases when > > necessary, in a consistent way. > > > > At a lower level, the use case manager works by configuring the sound card > > ALSA kcontrols to change the hardware digital and analog audio routing to > > match the requested device use case. > > > > The use case manager kcontrol configurations are stored in easy to modify text > > files. An audio use case can be defined by a **verb** and **device** parameter. > > > > The verb describes the use case action i.e. a phone call, listening to music, > > recording a conversation etc. The device describes the physical audio capture > > and playback hardware i.e. headphones, phone handset, bluetooth headset, etc. > > > > > > OPTIONS > > ======= > > > > Available options: > > > > **-h**, **--help** > > this help > > > > **-c**, **--card** `NAME` > > open card NAME > > > > **-i**, **--interactive** > > interactive mode > > > > **-b**, **--batch** `FILE` > > batch mode (use ``'-'`` for the stdin input) > > > > **-n**, **--no-open** > > do not open first card found > > > > > > Available commands: > > > > ``open`` `NAME` > > open card NAME. > > > > valid names are sound card names as listed in ``/usr/share/alsa/ucm``. > > > > ``reset`` > > reset sound card to default state. > > > > ``reload`` > > reload configuration. > > > > ``listcards`` > > list available cards. > > > > ``list`` `IDENTIFIER` > > list command, for items returning two entries (value+comment). > > > > the value of the `IDENTIFIER` argument can can be: > > > > - ``_verbs`` - get verb list (in pair verb+comment) > > - ``_devices[/{verb}]`` - get list of supported devices (in pair device+comment) > > - ``_modifiers[/{verb}]`` - get list of supported modifiers (in pair modifier+comment) > > > > The forms without the trailing ``/{verb}`` are valid only after a specific > > verb has been set. > > > > ``list1`` `IDENTIFIER` > > list command, for lists returning one item per entry. > > > > the value of the `IDENTIFIER` argument can vary depending on the context, > > it can be: > > > > - ``TQ[/{verb}]`` - get list of Tone Quality identifiers > > - ``_enadevs`` - get list of enabled devices > > - ``_enamods`` - get list of enabled modifiers > > - ``_supporteddevs/{modifier}|{device}[/{verb}]`` - list of supported devices > > - ``_conflictingdevs/{modifier}|{device}[/{verb}]`` - list of conflicting devices > > > > ``get`` `IDENTIFIER` > > get string value. > > > > the value of the `IDENTIFIER` argument can can be: > > > > - ``_verb`` - return current verb > > - ``[=]{NAME}[/[{modifier}|{/device}][/{verb}]]`` (For valid NAMEs look at the > > ALSA `Use Case Interface`_) > > > > > > ``geti`` `IDENTIFIER` > > get integer value. > > > > the value of the `IDENTIFIER` argument can can be: > > > > - ``_devstatus/{device}`` > > - ``_modtstaus/{device}`` > > > > ``set`` `IDENTIFIER` `VALUE` > > set string value > > > > The value of the `IDENTIFIER` argument can can be: > > > > - ``_verb`` - set the verb to `VALUE` > > - ``_enadev`` - enable the device specified by `VALUE` > > - ``_disdev`` - disable the device specified by `VALUE` > > - ``_swdev/{old_device}`` - switche device: > > > > - disable `old_device` and then enable the device specified by > > `VALUE` > > - if no device was enabled just return > > > > - ``_enamod`` - enable the modifier specified by `VALUE` > > - ``_dismod`` - disable the modifier specified by `VALUE` > > - ``_swmod/{old_modifier}`` - switch modifier: > > > > - disable `old_modifier` and then enable the modifier specified by > > `VALUE` > > - if no modifier was enabled just return > > > > Note that the identifiers referring to devices and modifiers are valid > > only after setting a verb. > > > > ``h``, ``help`` > > help > > > > ``q``, ``quit`` > > quit > > > > > > FILES > > ===== > > > > The master use case files for each supported sound card are in ``/usr/share/alsa/ucm``. > > > > For example, the master use case file for the `Pandaboard` card is in > > ``/usr/share/alsa/ucm/PandaBoard/PandaBoard.conf``, this file lists all the > > supported use cases, e.g. > > > > :: > > > > SectionUseCase."HiFi" { > > File "hifi" > > Comment "Play HiFi quality Music." > > } > > ... > > > > > > Each use case defines a _verb, which is described in the file specified in > > the ``File`` directive, like above. > > > > The ``HiFi`` verb above is described in > > ``/usr/share/alsa/ucm/PandaBoard/hifi``. > > > > For more details on the syntax of UCM files, see the alsa-lib source code: > > http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=src/ucm/parser.c > > > > > > EXAMPLES OF USE > > =============== > > > > Some commands, like for instance ``list _devices``, > > can only work after setting a ``_verb`` in the **same execution**, for > > instance this sequence doesn't work: > > > > :: > > > > # alsaucm -c bytcr-rt5640 set _verb HiFi > > # alsaucm -c bytcr-rt5640 list _devices > > > > > > However this command does: > > > > :: > > > > # alsaucm -n -b - <<EOM > > open bytcr-rt5640 > > set _verb HiFi > > list _devices > > EOM > > > > > > An example of setting the `Speaker` device for the `HiFi` verb of the > > `bytcr-rt5640` card: > > > > :: > > > > # alsaucm -n -b - <<EOM > > open bytcr-rt5640 > > reset > > set _verb HiFi > > set _enadev Speaker > > EOM > > > > > > > > SEE ALSO > > ======== > > > > * Use Case Interface: http://www.alsa-project.org/alsa-doc/alsa-lib/group__ucm.html > > > > .. _Use Case Interface: http://www.alsa-project.org/alsa-doc/alsa-lib/group__ucm.html > > > > BUGS > > ==== > > > > None known. > > > > -- Antonio Ospite https://ao2.it https://twitter.com/ao2it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [alsa-utils] alsaucm should come with a man page 2016-10-26 17:01 ` Antonio Ospite @ 2016-12-02 12:11 ` Antonio Ospite 2016-12-02 12:59 ` Liam Girdwood 0 siblings, 1 reply; 10+ messages in thread From: Antonio Ospite @ 2016-12-02 12:11 UTC (permalink / raw) To: Takashi Iwai Cc: Liam Girdwood, alsa-devel, Pierre-Louis Bossart, Liam Girdwood On Wed, 26 Oct 2016 19:01:31 +0200 Antonio Ospite <ao2@ao2.it> wrote: > On Thu, 29 Sep 2016 10:00:48 +0200 > Takashi Iwai <tiwai@suse.de> wrote: > [...] > > > > Liam, could you review the content? > > > > Ping, plus adding Liam's Intel address just in case. > Re-ping. The man page content is below but I can resend it if it's easier to review. Thanks, Antonio > > > > ========= > > > alsaucm > > > ========= > > > > > > --------------------- > > > ALSA Use Case Manager > > > --------------------- > > > > > > :Author: Antonio Ospite <ao2@ao2.it> > > > :Date: 2016-09-22 > > > :Copyright: GPLv2+ > > > :Manual section: 1 > > > :Manual group: General Commands Manual > > > > > > SYNOPSIS > > > ======== > > > > > > *alsaucm* <options> [command] > > > > > > DESCRIPTION > > > =========== > > > > > > alsaucm (ALSA Use Case Manager) is a program to use the ALSA `Use Case > > > Interface`_ from the command line. > > > > > > On complex sound cards, setting up audio routes is not trivial and mixer > > > settings can conflict one another preventing the audio card to work at all. > > > > > > The ALSA Use Case Manager is a mechanism for controlling complex audio > > > hardware establishing a relationship between hardware configurations and > > > meaningful use cases that the end-user can relate with. > > > > > > The use case manager can also be used to switch between use cases when > > > necessary, in a consistent way. > > > > > > At a lower level, the use case manager works by configuring the sound card > > > ALSA kcontrols to change the hardware digital and analog audio routing to > > > match the requested device use case. > > > > > > The use case manager kcontrol configurations are stored in easy to modify text > > > files. An audio use case can be defined by a **verb** and **device** parameter. > > > > > > The verb describes the use case action i.e. a phone call, listening to music, > > > recording a conversation etc. The device describes the physical audio capture > > > and playback hardware i.e. headphones, phone handset, bluetooth headset, etc. > > > > > > > > > OPTIONS > > > ======= > > > > > > Available options: > > > > > > **-h**, **--help** > > > this help > > > > > > **-c**, **--card** `NAME` > > > open card NAME > > > > > > **-i**, **--interactive** > > > interactive mode > > > > > > **-b**, **--batch** `FILE` > > > batch mode (use ``'-'`` for the stdin input) > > > > > > **-n**, **--no-open** > > > do not open first card found > > > > > > > > > Available commands: > > > > > > ``open`` `NAME` > > > open card NAME. > > > > > > valid names are sound card names as listed in ``/usr/share/alsa/ucm``. > > > > > > ``reset`` > > > reset sound card to default state. > > > > > > ``reload`` > > > reload configuration. > > > > > > ``listcards`` > > > list available cards. > > > > > > ``list`` `IDENTIFIER` > > > list command, for items returning two entries (value+comment). > > > > > > the value of the `IDENTIFIER` argument can can be: > > > > > > - ``_verbs`` - get verb list (in pair verb+comment) > > > - ``_devices[/{verb}]`` - get list of supported devices (in pair device+comment) > > > - ``_modifiers[/{verb}]`` - get list of supported modifiers (in pair modifier+comment) > > > > > > The forms without the trailing ``/{verb}`` are valid only after a specific > > > verb has been set. > > > > > > ``list1`` `IDENTIFIER` > > > list command, for lists returning one item per entry. > > > > > > the value of the `IDENTIFIER` argument can vary depending on the context, > > > it can be: > > > > > > - ``TQ[/{verb}]`` - get list of Tone Quality identifiers > > > - ``_enadevs`` - get list of enabled devices > > > - ``_enamods`` - get list of enabled modifiers > > > - ``_supporteddevs/{modifier}|{device}[/{verb}]`` - list of supported devices > > > - ``_conflictingdevs/{modifier}|{device}[/{verb}]`` - list of conflicting devices > > > > > > ``get`` `IDENTIFIER` > > > get string value. > > > > > > the value of the `IDENTIFIER` argument can can be: > > > > > > - ``_verb`` - return current verb > > > - ``[=]{NAME}[/[{modifier}|{/device}][/{verb}]]`` (For valid NAMEs look at the > > > ALSA `Use Case Interface`_) > > > > > > > > > ``geti`` `IDENTIFIER` > > > get integer value. > > > > > > the value of the `IDENTIFIER` argument can can be: > > > > > > - ``_devstatus/{device}`` > > > - ``_modtstaus/{device}`` > > > > > > ``set`` `IDENTIFIER` `VALUE` > > > set string value > > > > > > The value of the `IDENTIFIER` argument can can be: > > > > > > - ``_verb`` - set the verb to `VALUE` > > > - ``_enadev`` - enable the device specified by `VALUE` > > > - ``_disdev`` - disable the device specified by `VALUE` > > > - ``_swdev/{old_device}`` - switche device: > > > > > > - disable `old_device` and then enable the device specified by > > > `VALUE` > > > - if no device was enabled just return > > > > > > - ``_enamod`` - enable the modifier specified by `VALUE` > > > - ``_dismod`` - disable the modifier specified by `VALUE` > > > - ``_swmod/{old_modifier}`` - switch modifier: > > > > > > - disable `old_modifier` and then enable the modifier specified by > > > `VALUE` > > > - if no modifier was enabled just return > > > > > > Note that the identifiers referring to devices and modifiers are valid > > > only after setting a verb. > > > > > > ``h``, ``help`` > > > help > > > > > > ``q``, ``quit`` > > > quit > > > > > > > > > FILES > > > ===== > > > > > > The master use case files for each supported sound card are in ``/usr/share/alsa/ucm``. > > > > > > For example, the master use case file for the `Pandaboard` card is in > > > ``/usr/share/alsa/ucm/PandaBoard/PandaBoard.conf``, this file lists all the > > > supported use cases, e.g. > > > > > > :: > > > > > > SectionUseCase."HiFi" { > > > File "hifi" > > > Comment "Play HiFi quality Music." > > > } > > > ... > > > > > > > > > Each use case defines a _verb, which is described in the file specified in > > > the ``File`` directive, like above. > > > > > > The ``HiFi`` verb above is described in > > > ``/usr/share/alsa/ucm/PandaBoard/hifi``. > > > > > > For more details on the syntax of UCM files, see the alsa-lib source code: > > > http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=src/ucm/parser.c > > > > > > > > > EXAMPLES OF USE > > > =============== > > > > > > Some commands, like for instance ``list _devices``, > > > can only work after setting a ``_verb`` in the **same execution**, for > > > instance this sequence doesn't work: > > > > > > :: > > > > > > # alsaucm -c bytcr-rt5640 set _verb HiFi > > > # alsaucm -c bytcr-rt5640 list _devices > > > > > > > > > However this command does: > > > > > > :: > > > > > > # alsaucm -n -b - <<EOM > > > open bytcr-rt5640 > > > set _verb HiFi > > > list _devices > > > EOM > > > > > > > > > An example of setting the `Speaker` device for the `HiFi` verb of the > > > `bytcr-rt5640` card: > > > > > > :: > > > > > > # alsaucm -n -b - <<EOM > > > open bytcr-rt5640 > > > reset > > > set _verb HiFi > > > set _enadev Speaker > > > EOM > > > > > > > > > > > > SEE ALSO > > > ======== > > > > > > * Use Case Interface: http://www.alsa-project.org/alsa-doc/alsa-lib/group__ucm.html > > > > > > .. _Use Case Interface: http://www.alsa-project.org/alsa-doc/alsa-lib/group__ucm.html > > > > > > BUGS > > > ==== > > > > > > None known. > > > > > > > -- Antonio Ospite https://ao2.it https://twitter.com/ao2it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [alsa-utils] alsaucm should come with a man page 2016-12-02 12:11 ` Antonio Ospite @ 2016-12-02 12:59 ` Liam Girdwood 2016-12-02 13:23 ` Takashi Iwai 0 siblings, 1 reply; 10+ messages in thread From: Liam Girdwood @ 2016-12-02 12:59 UTC (permalink / raw) To: Antonio Ospite Cc: Takashi Iwai, alsa-devel, mengdong.lin, Pierre-Louis Bossart On Fri, 2016-12-02 at 13:11 +0100, Antonio Ospite wrote: > On Wed, 26 Oct 2016 19:01:31 +0200 > Antonio Ospite <ao2@ao2.it> wrote: > > > On Thu, 29 Sep 2016 10:00:48 +0200 > > Takashi Iwai <tiwai@suse.de> wrote: > > > [...] > > > > > > Liam, could you review the content? Apologies. Looks good :) Acked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com> > > > > > > > Ping, plus adding Liam's Intel address just in case. > > > > Re-ping. > > The man page content is below but I can resend it if it's easier to > review. > > Thanks, > Antonio > > > > > > > ========= > > > > alsaucm > > > > ========= > > > > > > > > --------------------- > > > > ALSA Use Case Manager > > > > --------------------- > > > > > > > > :Author: Antonio Ospite <ao2@ao2.it> > > > > :Date: 2016-09-22 > > > > :Copyright: GPLv2+ > > > > :Manual section: 1 > > > > :Manual group: General Commands Manual > > > > > > > > SYNOPSIS > > > > ======== > > > > > > > > *alsaucm* <options> [command] > > > > > > > > DESCRIPTION > > > > =========== > > > > > > > > alsaucm (ALSA Use Case Manager) is a program to use the ALSA `Use Case > > > > Interface`_ from the command line. > > > > > > > > On complex sound cards, setting up audio routes is not trivial and mixer > > > > settings can conflict one another preventing the audio card to work at all. > > > > > > > > The ALSA Use Case Manager is a mechanism for controlling complex audio > > > > hardware establishing a relationship between hardware configurations and > > > > meaningful use cases that the end-user can relate with. > > > > > > > > The use case manager can also be used to switch between use cases when > > > > necessary, in a consistent way. > > > > > > > > At a lower level, the use case manager works by configuring the sound card > > > > ALSA kcontrols to change the hardware digital and analog audio routing to > > > > match the requested device use case. > > > > > > > > The use case manager kcontrol configurations are stored in easy to modify text > > > > files. An audio use case can be defined by a **verb** and **device** parameter. > > > > > > > > The verb describes the use case action i.e. a phone call, listening to music, > > > > recording a conversation etc. The device describes the physical audio capture > > > > and playback hardware i.e. headphones, phone handset, bluetooth headset, etc. > > > > > > > > > > > > OPTIONS > > > > ======= > > > > > > > > Available options: > > > > > > > > **-h**, **--help** > > > > this help > > > > > > > > **-c**, **--card** `NAME` > > > > open card NAME > > > > > > > > **-i**, **--interactive** > > > > interactive mode > > > > > > > > **-b**, **--batch** `FILE` > > > > batch mode (use ``'-'`` for the stdin input) > > > > > > > > **-n**, **--no-open** > > > > do not open first card found > > > > > > > > > > > > Available commands: > > > > > > > > ``open`` `NAME` > > > > open card NAME. > > > > > > > > valid names are sound card names as listed in ``/usr/share/alsa/ucm``. > > > > > > > > ``reset`` > > > > reset sound card to default state. > > > > > > > > ``reload`` > > > > reload configuration. > > > > > > > > ``listcards`` > > > > list available cards. > > > > > > > > ``list`` `IDENTIFIER` > > > > list command, for items returning two entries (value+comment). > > > > > > > > the value of the `IDENTIFIER` argument can can be: > > > > > > > > - ``_verbs`` - get verb list (in pair verb+comment) > > > > - ``_devices[/{verb}]`` - get list of supported devices (in pair device+comment) > > > > - ``_modifiers[/{verb}]`` - get list of supported modifiers (in pair modifier+comment) > > > > > > > > The forms without the trailing ``/{verb}`` are valid only after a specific > > > > verb has been set. > > > > > > > > ``list1`` `IDENTIFIER` > > > > list command, for lists returning one item per entry. > > > > > > > > the value of the `IDENTIFIER` argument can vary depending on the context, > > > > it can be: > > > > > > > > - ``TQ[/{verb}]`` - get list of Tone Quality identifiers > > > > - ``_enadevs`` - get list of enabled devices > > > > - ``_enamods`` - get list of enabled modifiers > > > > - ``_supporteddevs/{modifier}|{device}[/{verb}]`` - list of supported devices > > > > - ``_conflictingdevs/{modifier}|{device}[/{verb}]`` - list of conflicting devices > > > > > > > > ``get`` `IDENTIFIER` > > > > get string value. > > > > > > > > the value of the `IDENTIFIER` argument can can be: > > > > > > > > - ``_verb`` - return current verb > > > > - ``[=]{NAME}[/[{modifier}|{/device}][/{verb}]]`` (For valid NAMEs look at the > > > > ALSA `Use Case Interface`_) > > > > > > > > > > > > ``geti`` `IDENTIFIER` > > > > get integer value. > > > > > > > > the value of the `IDENTIFIER` argument can can be: > > > > > > > > - ``_devstatus/{device}`` > > > > - ``_modtstaus/{device}`` > > > > > > > > ``set`` `IDENTIFIER` `VALUE` > > > > set string value > > > > > > > > The value of the `IDENTIFIER` argument can can be: > > > > > > > > - ``_verb`` - set the verb to `VALUE` > > > > - ``_enadev`` - enable the device specified by `VALUE` > > > > - ``_disdev`` - disable the device specified by `VALUE` > > > > - ``_swdev/{old_device}`` - switche device: > > > > > > > > - disable `old_device` and then enable the device specified by > > > > `VALUE` > > > > - if no device was enabled just return > > > > > > > > - ``_enamod`` - enable the modifier specified by `VALUE` > > > > - ``_dismod`` - disable the modifier specified by `VALUE` > > > > - ``_swmod/{old_modifier}`` - switch modifier: > > > > > > > > - disable `old_modifier` and then enable the modifier specified by > > > > `VALUE` > > > > - if no modifier was enabled just return > > > > > > > > Note that the identifiers referring to devices and modifiers are valid > > > > only after setting a verb. > > > > > > > > ``h``, ``help`` > > > > help > > > > > > > > ``q``, ``quit`` > > > > quit > > > > > > > > > > > > FILES > > > > ===== > > > > > > > > The master use case files for each supported sound card are in ``/usr/share/alsa/ucm``. > > > > > > > > For example, the master use case file for the `Pandaboard` card is in > > > > ``/usr/share/alsa/ucm/PandaBoard/PandaBoard.conf``, this file lists all the > > > > supported use cases, e.g. > > > > > > > > :: > > > > > > > > SectionUseCase."HiFi" { > > > > File "hifi" > > > > Comment "Play HiFi quality Music." > > > > } > > > > ... > > > > > > > > > > > > Each use case defines a _verb, which is described in the file specified in > > > > the ``File`` directive, like above. > > > > > > > > The ``HiFi`` verb above is described in > > > > ``/usr/share/alsa/ucm/PandaBoard/hifi``. > > > > > > > > For more details on the syntax of UCM files, see the alsa-lib source code: > > > > http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=src/ucm/parser.c > > > > > > > > > > > > EXAMPLES OF USE > > > > =============== > > > > > > > > Some commands, like for instance ``list _devices``, > > > > can only work after setting a ``_verb`` in the **same execution**, for > > > > instance this sequence doesn't work: > > > > > > > > :: > > > > > > > > # alsaucm -c bytcr-rt5640 set _verb HiFi > > > > # alsaucm -c bytcr-rt5640 list _devices > > > > > > > > > > > > However this command does: > > > > > > > > :: > > > > > > > > # alsaucm -n -b - <<EOM > > > > open bytcr-rt5640 > > > > set _verb HiFi > > > > list _devices > > > > EOM > > > > > > > > > > > > An example of setting the `Speaker` device for the `HiFi` verb of the > > > > `bytcr-rt5640` card: > > > > > > > > :: > > > > > > > > # alsaucm -n -b - <<EOM > > > > open bytcr-rt5640 > > > > reset > > > > set _verb HiFi > > > > set _enadev Speaker > > > > EOM > > > > > > > > > > > > > > > > SEE ALSO > > > > ======== > > > > > > > > * Use Case Interface: http://www.alsa-project.org/alsa-doc/alsa-lib/group__ucm.html > > > > > > > > .. _Use Case Interface: http://www.alsa-project.org/alsa-doc/alsa-lib/group__ucm.html > > > > > > > > BUGS > > > > ==== > > > > > > > > None known. > > > > > > > > > > > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [alsa-utils] alsaucm should come with a man page 2016-12-02 12:59 ` Liam Girdwood @ 2016-12-02 13:23 ` Takashi Iwai 2016-12-02 13:47 ` Antonio Ospite 0 siblings, 1 reply; 10+ messages in thread From: Takashi Iwai @ 2016-12-02 13:23 UTC (permalink / raw) To: Liam Girdwood Cc: mengdong.lin, alsa-devel, Antonio Ospite, Pierre-Louis Bossart On Fri, 02 Dec 2016 13:59:27 +0100, Liam Girdwood wrote: > > On Fri, 2016-12-02 at 13:11 +0100, Antonio Ospite wrote: > > On Wed, 26 Oct 2016 19:01:31 +0200 > > Antonio Ospite <ao2@ao2.it> wrote: > > > > > On Thu, 29 Sep 2016 10:00:48 +0200 > > > Takashi Iwai <tiwai@suse.de> wrote: > > > > > [...] > > > > > > > > Liam, could you review the content? > > Apologies. Looks good :) > > Acked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com> Thanks. Antonio, could you submit as a proper patch? Since we have no rst conversion so far in alsa-utils package, I prefer the raw *roff format at this time. Or, you can introduce the configure change to support ReST in the patchset. It's up to you :) Takashi > > > > > > > > > > Ping, plus adding Liam's Intel address just in case. > > > > > > > Re-ping. > > > > The man page content is below but I can resend it if it's easier to > > review. > > > > Thanks, > > Antonio > > > > > > > > > > ========= > > > > > alsaucm > > > > > ========= > > > > > > > > > > --------------------- > > > > > ALSA Use Case Manager > > > > > --------------------- > > > > > > > > > > :Author: Antonio Ospite <ao2@ao2.it> > > > > > :Date: 2016-09-22 > > > > > :Copyright: GPLv2+ > > > > > :Manual section: 1 > > > > > :Manual group: General Commands Manual > > > > > > > > > > SYNOPSIS > > > > > ======== > > > > > > > > > > *alsaucm* <options> [command] > > > > > > > > > > DESCRIPTION > > > > > =========== > > > > > > > > > > alsaucm (ALSA Use Case Manager) is a program to use the ALSA `Use Case > > > > > Interface`_ from the command line. > > > > > > > > > > On complex sound cards, setting up audio routes is not trivial and mixer > > > > > settings can conflict one another preventing the audio card to work at all. > > > > > > > > > > The ALSA Use Case Manager is a mechanism for controlling complex audio > > > > > hardware establishing a relationship between hardware configurations and > > > > > meaningful use cases that the end-user can relate with. > > > > > > > > > > The use case manager can also be used to switch between use cases when > > > > > necessary, in a consistent way. > > > > > > > > > > At a lower level, the use case manager works by configuring the sound card > > > > > ALSA kcontrols to change the hardware digital and analog audio routing to > > > > > match the requested device use case. > > > > > > > > > > The use case manager kcontrol configurations are stored in easy to modify text > > > > > files. An audio use case can be defined by a **verb** and **device** parameter. > > > > > > > > > > The verb describes the use case action i.e. a phone call, listening to music, > > > > > recording a conversation etc. The device describes the physical audio capture > > > > > and playback hardware i.e. headphones, phone handset, bluetooth headset, etc. > > > > > > > > > > > > > > > OPTIONS > > > > > ======= > > > > > > > > > > Available options: > > > > > > > > > > **-h**, **--help** > > > > > this help > > > > > > > > > > **-c**, **--card** `NAME` > > > > > open card NAME > > > > > > > > > > **-i**, **--interactive** > > > > > interactive mode > > > > > > > > > > **-b**, **--batch** `FILE` > > > > > batch mode (use ``'-'`` for the stdin input) > > > > > > > > > > **-n**, **--no-open** > > > > > do not open first card found > > > > > > > > > > > > > > > Available commands: > > > > > > > > > > ``open`` `NAME` > > > > > open card NAME. > > > > > > > > > > valid names are sound card names as listed in ``/usr/share/alsa/ucm``. > > > > > > > > > > ``reset`` > > > > > reset sound card to default state. > > > > > > > > > > ``reload`` > > > > > reload configuration. > > > > > > > > > > ``listcards`` > > > > > list available cards. > > > > > > > > > > ``list`` `IDENTIFIER` > > > > > list command, for items returning two entries (value+comment). > > > > > > > > > > the value of the `IDENTIFIER` argument can can be: > > > > > > > > > > - ``_verbs`` - get verb list (in pair verb+comment) > > > > > - ``_devices[/{verb}]`` - get list of supported devices (in pair device+comment) > > > > > - ``_modifiers[/{verb}]`` - get list of supported modifiers (in pair modifier+comment) > > > > > > > > > > The forms without the trailing ``/{verb}`` are valid only after a specific > > > > > verb has been set. > > > > > > > > > > ``list1`` `IDENTIFIER` > > > > > list command, for lists returning one item per entry. > > > > > > > > > > the value of the `IDENTIFIER` argument can vary depending on the context, > > > > > it can be: > > > > > > > > > > - ``TQ[/{verb}]`` - get list of Tone Quality identifiers > > > > > - ``_enadevs`` - get list of enabled devices > > > > > - ``_enamods`` - get list of enabled modifiers > > > > > - ``_supporteddevs/{modifier}|{device}[/{verb}]`` - list of supported devices > > > > > - ``_conflictingdevs/{modifier}|{device}[/{verb}]`` - list of conflicting devices > > > > > > > > > > ``get`` `IDENTIFIER` > > > > > get string value. > > > > > > > > > > the value of the `IDENTIFIER` argument can can be: > > > > > > > > > > - ``_verb`` - return current verb > > > > > - ``[=]{NAME}[/[{modifier}|{/device}][/{verb}]]`` (For valid NAMEs look at the > > > > > ALSA `Use Case Interface`_) > > > > > > > > > > > > > > > ``geti`` `IDENTIFIER` > > > > > get integer value. > > > > > > > > > > the value of the `IDENTIFIER` argument can can be: > > > > > > > > > > - ``_devstatus/{device}`` > > > > > - ``_modtstaus/{device}`` > > > > > > > > > > ``set`` `IDENTIFIER` `VALUE` > > > > > set string value > > > > > > > > > > The value of the `IDENTIFIER` argument can can be: > > > > > > > > > > - ``_verb`` - set the verb to `VALUE` > > > > > - ``_enadev`` - enable the device specified by `VALUE` > > > > > - ``_disdev`` - disable the device specified by `VALUE` > > > > > - ``_swdev/{old_device}`` - switche device: > > > > > > > > > > - disable `old_device` and then enable the device specified by > > > > > `VALUE` > > > > > - if no device was enabled just return > > > > > > > > > > - ``_enamod`` - enable the modifier specified by `VALUE` > > > > > - ``_dismod`` - disable the modifier specified by `VALUE` > > > > > - ``_swmod/{old_modifier}`` - switch modifier: > > > > > > > > > > - disable `old_modifier` and then enable the modifier specified by > > > > > `VALUE` > > > > > - if no modifier was enabled just return > > > > > > > > > > Note that the identifiers referring to devices and modifiers are valid > > > > > only after setting a verb. > > > > > > > > > > ``h``, ``help`` > > > > > help > > > > > > > > > > ``q``, ``quit`` > > > > > quit > > > > > > > > > > > > > > > FILES > > > > > ===== > > > > > > > > > > The master use case files for each supported sound card are in ``/usr/share/alsa/ucm``. > > > > > > > > > > For example, the master use case file for the `Pandaboard` card is in > > > > > ``/usr/share/alsa/ucm/PandaBoard/PandaBoard.conf``, this file lists all the > > > > > supported use cases, e.g. > > > > > > > > > > :: > > > > > > > > > > SectionUseCase."HiFi" { > > > > > File "hifi" > > > > > Comment "Play HiFi quality Music." > > > > > } > > > > > ... > > > > > > > > > > > > > > > Each use case defines a _verb, which is described in the file specified in > > > > > the ``File`` directive, like above. > > > > > > > > > > The ``HiFi`` verb above is described in > > > > > ``/usr/share/alsa/ucm/PandaBoard/hifi``. > > > > > > > > > > For more details on the syntax of UCM files, see the alsa-lib source code: > > > > > http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=src/ucm/parser.c > > > > > > > > > > > > > > > EXAMPLES OF USE > > > > > =============== > > > > > > > > > > Some commands, like for instance ``list _devices``, > > > > > can only work after setting a ``_verb`` in the **same execution**, for > > > > > instance this sequence doesn't work: > > > > > > > > > > :: > > > > > > > > > > # alsaucm -c bytcr-rt5640 set _verb HiFi > > > > > # alsaucm -c bytcr-rt5640 list _devices > > > > > > > > > > > > > > > However this command does: > > > > > > > > > > :: > > > > > > > > > > # alsaucm -n -b - <<EOM > > > > > open bytcr-rt5640 > > > > > set _verb HiFi > > > > > list _devices > > > > > EOM > > > > > > > > > > > > > > > An example of setting the `Speaker` device for the `HiFi` verb of the > > > > > `bytcr-rt5640` card: > > > > > > > > > > :: > > > > > > > > > > # alsaucm -n -b - <<EOM > > > > > open bytcr-rt5640 > > > > > reset > > > > > set _verb HiFi > > > > > set _enadev Speaker > > > > > EOM > > > > > > > > > > > > > > > > > > > > SEE ALSO > > > > > ======== > > > > > > > > > > * Use Case Interface: http://www.alsa-project.org/alsa-doc/alsa-lib/group__ucm.html > > > > > > > > > > .. _Use Case Interface: http://www.alsa-project.org/alsa-doc/alsa-lib/group__ucm.html > > > > > > > > > > BUGS > > > > > ==== > > > > > > > > > > None known. > > > > > > > > > > > > > > > > > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [alsa-utils] alsaucm should come with a man page 2016-12-02 13:23 ` Takashi Iwai @ 2016-12-02 13:47 ` Antonio Ospite 0 siblings, 0 replies; 10+ messages in thread From: Antonio Ospite @ 2016-12-02 13:47 UTC (permalink / raw) To: Takashi Iwai Cc: Liam Girdwood, alsa-devel, mengdong.lin, Pierre-Louis Bossart On Fri, 02 Dec 2016 14:23:18 +0100 Takashi Iwai <tiwai@suse.de> wrote: > On Fri, 02 Dec 2016 13:59:27 +0100, > Liam Girdwood wrote: > > > > On Fri, 2016-12-02 at 13:11 +0100, Antonio Ospite wrote: > > > On Wed, 26 Oct 2016 19:01:31 +0200 > > > Antonio Ospite <ao2@ao2.it> wrote: > > > > > > > On Thu, 29 Sep 2016 10:00:48 +0200 > > > > Takashi Iwai <tiwai@suse.de> wrote: > > > > > > > [...] > > > > > > > > > > Liam, could you review the content? > > > > Apologies. Looks good :) > > > > Acked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com> > > Thanks. Antonio, could you submit as a proper patch? > Since we have no rst conversion so far in alsa-utils package, I prefer > the raw *roff format at this time. > > Or, you can introduce the configure change to support ReST in the > patchset. It's up to you :) > > I'll look into adding the configure changes, and report back next week. Thanks, Antonio -- Antonio Ospite https://ao2.it https://twitter.com/ao2it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2016-12-02 13:47 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-07-27 9:48 [alsa-utils] alsaucm should come with a man page Antonio Ospite 2016-08-03 15:57 ` Takashi Iwai 2016-08-08 16:30 ` Antonio Ospite 2016-09-23 16:37 ` Antonio Ospite 2016-09-29 8:00 ` Takashi Iwai 2016-10-26 17:01 ` Antonio Ospite 2016-12-02 12:11 ` Antonio Ospite 2016-12-02 12:59 ` Liam Girdwood 2016-12-02 13:23 ` Takashi Iwai 2016-12-02 13:47 ` Antonio Ospite
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.