- Generated by
1.16.1
|
ALSA project - the C library reference
|
The ALSA Use Case Configuration. See ALSA Use Case Configuration page for more details.
The use case configuration files use Configuration files syntax to define the static configuration tree. This tree is evaluated (modified) at runtime according the conditions and dynamic variables in the configuration tree. The result is parsed and exported to the applications using Use Case Interface API.
The lookup paths are describen in ucm.conf file. The configuration structure looks like:
Each sound card has a master sound card file that lists all the supported use case verbs for that sound card. i.e.:
The verb configuration file defines devices, modifier and initialization sequences. It is something like a sound profile.
| Command name | Description |
|---|---|
| enadev2 ARG | execute device enable sequence |
| disdev2 ARG | execute device disable sequence |
| disdevall "" | execute device disable sequence for all devices in verb |
| cdev ARG | ALSA control device name for snd_ctl_open() |
| cset ARG | ALSA control set - snd_ctl_ascii_elem_id_parse() + snd_ctl_ascii_value_parse() |
| cset-new ARG | Create new ALSA user control element - snd_ctl_ascii_elem_id_parse() + description |
| ctl-remove ARG | Remove ALSA user control element - snd_ctl_ascii_elem_id_parse() |
| sysw ARG | write to sysfs tree |
| usleep ARG | sleep for specified amount of microseconds |
| msleep ARG | sleep for specified amount of milliseconds |
| exec ARG | execute a specific command (without shell - man execv) |
| shell ARG | execute a specific command (using shell - man system) |
| cfg-save ARG | save LibraryConfig to a file |
See the SND_USE_CASE_VERB constains like SND_USE_CASE_VERB_HIFI for the full list of known verbs.
See the SND_USE_CASE_DEV constants like SND_USE_CASE_DEV_SPEAKER for the full list of known devices. If multiple devices with the same name exists, the number suffixes should be added to these names like HDMI1,HDMI2,HDMI3 etc. No number gaps are allowed. The names with numbers must be continuous. It is allowed to put a whitespace between name and index (like 'Line 1') for the better readability. The device names 'Line 1' and 'Line1' are equal for this purpose.
Starting with Syntax 8, device names can include a colon (':') character to enable automatic device index assignment. When a device name contains a colon, the UCM parser will automatically assign an available numeric index and remove everything after and including the colon character.
The automatic assignment ensures that the generated device name is unique within the verb by finding the first available index starting from 1. If a name conflict is detected, the index is automatically incremented until a unique name is found (up to index 99).
This feature is particularly useful for dynamically creating multiple instances of similar devices without manually managing index numbers. The text after the colon is required and serves as a descriptive identifier in the source configuration to help distinguish between devices, but is not part of the final device name.
Example - Automatic HDMI device indexing:
Example - Automatic Line device indexing with descriptive identifiers:
Example - Mixed manual and automatic indexing:
If EnableSequence/DisableSequence controls independent paths in the hardware it is also recommended to split playback and capture UCM devices and use the number suffixes. Example use case: Use the integrated microphone in the laptop instead the microphone in headphones.
The preference of the devices is determined by the priority value (higher value = higher priority).
Starting with Syntax 8, devices are automatically sorted based on their priority values. The sorting is performed at the end of device management processing, after device renaming and index assignment.
The priority key selection order is:
Devices are sorted in descending order of priority (higher priority values appear first in the device list). When two devices have the same priority value, they are sorted alphabetically by device name.
Example - Device priority ordering:
In this example, the device list will be ordered as: Headphones (200), HDMI (150), Speaker (100).
See the SND_USE_CASE_MOD constants like SND_USE_CASE_MOD_ECHO_REF for the full list of known modifiers.
The FixedBootSequence is executed at each boot. The BootSequence is executed only if the card's configuration is missing. The purpose is to let the users modify the configuration like volumes or switches. The alsactl ensures the persistency (store the state of the controls to the /var tree and loads the previous state in the next boot).
The BootCardGroup value in ValueGlobals allows multiple sound cards to coordinate their boot sequences. This value is detected at boot (alsactl/udev/systemd) time. Boot tools can provide boot synchronization information through a control element named 'Boot' with 64-bit integer type. When present, the UCM library uses this control element to coordinate initialization timing.
The 'Boot' control element contains:
The UCM open call waits until the boot timeout has passed or until restore state is notified through the synchronization Boot element. The timeout defaults to 30 seconds and can be customized using 'BootCardSyncTime' in 'ValueGlobals' (maximum 240 seconds).
If the 'Boot' control element is not present, no boot synchronization is performed.
Other cards in the group (primary card number is different) will have the "Linked" value set to "1", allowing UCM configuration files to detect and handle secondary cards appropriately.
Example configuration:
It is expected that the applications handle the volume settings. It is not recommended to set the fixed values for the volume settings in the Enable / Disable sequences for verbs or devices, if the device exports the hardware volume (MixerElem or Volume/Switch values). The default volume settings should be set in the BootSequence. The purpose for this scheme is to allow users to override defaults using the alsactl sound card state management.
Checklist:
The evaluation order may look a bit different from the user perspective. At first, the standard alsa-lib configuration tree is parsed. All other layers on top are working with this tree. It may shift / move the configuration blocks from the configuration files as they are placed to the tree internally.
Even if one or both conditions are evaluated as true, the variable VAR will be evaluated always as B because the first If block was before the non-nested Define . The second If block was appended to the first If block (before Define in the configuration tree) in the text configuration parser.
Unless described, the syntax version 4 is used.
There are two ways to include other configuration files.
The static include is inherited from the standard alsa-lib configuration syntax. It can be placed anywhere in the configuration files. The search path is composed from the root alsa configuration path (usually _/usr/share/alsa_) and ucm2 directory.
The lazy include is evaluated at runtime. The root path is the ucm2 tree. The absolute include appends the ucm2 absolute path to the specified path. The relative include is relative to the file which contains the Include configuration block.
The evaluation of the static configuration tree is proceed in the specific order (see table bellow). When the dynamic configuration tree changes, the evaluation sequence is restarted to evaluate all possible changes (new Define or Include or If blocks).
| Evaluation order | Configuration block | Evaluation restart |
|---|---|---|
| 1 | Define | No |
| 2 | Include | Yes |
| 3 | Variant | Yes |
| 4 | Macro | Yes |
| 5 | Repeat | Yes |
| 6 | If | Yes |
The dynamic tree identifiers and assigned values in the configuration tree are substituted. The substitutes strings are in the table bellow.
| Substituted string | Value |
|---|---|
| ${LibCaps} | Library capabilities (string like 'a*b*c') [Syntax 8] |
| ${OpenName} | Original UCM card name (passed to snd_use_case_mgr_open()) |
| ${ConfLibDir} | Library top-level configuration directory (e.g. /usr/share/alsa) |
| ${ConfTopDir} | Top-level UCM configuration directory (e.g. /usr/share/alsa/ucm2) |
| ${ConfDir} | Card's UCM configuration directory (e.g. /usr/share/alsa/ucm2/conf.d/USB-Audio) |
| ${ConfName} | Configuration name (e.g. USB-Audio.conf) |
| ${CardNumber} | Real ALSA card number (or empty string for the virtual UCM card) |
| ${CardId} | ALSA card identifier (see snd_ctl_card_info_get_id()) |
| ${CardDriver} | ALSA card driver (see snd_ctl_card_info_get_driver()) |
| ${CardName} | ALSA card name (see snd_ctl_card_info_get_name()) |
| ${CardLongName} | ALSA card long name (see snd_ctl_card_info_get_longname()) |
| ${CardComponents} | ALSA card components (see snd_ctl_card_info_get_components()) |
| ${env:<str>} | Environment variable <str> |
| ${sys:<str>} | Contents of sysfs file <str> |
| ${sys-card:<str>} | Contents of sysfs file in /sys/class/sound/card? tree [Syntax 8] |
| ${var:<str>} | UCM parser variable (set using a Define block) |
| ${eval:<str>} | Evaluate expression like ($var+2)/3 [Syntax 5] |
| ${find-card:<str>} | Find a card - see Find card substitution section |
| ${find-device:<str>} | Find a device - see Find device substitution section |
| ${info-card:<str>} | Get card information - see Card info substitution section [Syntax 9] |
General note: If two dollars '$$' instead one dolar '$' are used for the substitution identification, the error is ignored (e.g. file does not exists in sysfs tree).
Note for var substitution: If the first characters is minus ('-') the empty string is substituted when the variable is not defined.
Note for sys and sys-card substitutions: since syntax 8, there is also extension to fetch data from given range with the optional conversion to hexadecimal format when the source file has binary contents.
Example - fetch bytes from positions 0x10..0x15 (6 bytes):
Example - fetch one byte from position 0x22:
Replace type=hex with type=ascii or omit this variable settings to work with ASCII characters.
None at the moment. The list will grow after Syntax 8 (library 1.2.14).
| Substituted string | Value |
|---|---|
| ${evali:<str>} | Evaluate expression like ($var+2)/3 [Syntax 6]; target node will be integer; substituted only in the LibraryConfig subtree |
This substitutions finds the ALSA card and returns the appropriate identifier or the card number (see return argument).
Usage example:
Arguments:
| Argument | Description |
|---|---|
| return | return value type (id, number), id is the default |
| field | field for the lookup (id, driver, name, longname, mixername, components) or variable name ($var) [Syntax 9] |
| regex | regex string for the field match or variable name ($var) [Syntax 9] |
Usage example:
Arguments:
| Argument | Description |
|---|---|
| type | device type (pcm) or variable name ($var) [Syntax 9] |
| stream | stream type (playback, capture), playback is default; variable name ($var) supported in Syntax 9 |
| field | field for the lookup (id, name, subname) or variable name ($var) [Syntax 9] |
| regex | regex string for the field match or variable name ($var) [Syntax 9] |
This substitution retrieves information about a specific ALSA card by card number or card ID and returns the requested field value.
Usage examples:
Arguments:
| Argument | Description |
|---|---|
| card | card number (integer), card ID (string), or variable name ($var) |
| field | field to retrieve (number, id, driver, name, longname, mixername, components) or variable name ($var) |
The card parameter can be either a card number (e.g., 0, 1, 2), a card ID string (e.g., "PCH", "acp", "Intel"), or a variable name prefixed with $ (e.g., $CardId).
The field parameter specifies which card information to return or can be a variable name prefixed with $ (e.g., $FieldName):
The variables can be defined and altered with the Define or DefineRegex blocks. The Define block looks like:
The DefineRegex allows substring extraction using regular expressions (POSIX extended regex). It can match patterns in strings and extract matched substrings into UCM variables.
| Field | Description |
|---|---|
| String | The input string to match the regex pattern against |
| Regex | POSIX extended regular expression pattern |
| Flags | Optional regex flags (see below) |
| Scheme | Matching scheme: "first" (default) or "all" [Syntax 9] |
The Flags field is optional and accepts the following characters:
| Flag | Description |
|---|---|
| e | Extended POSIX regex (REG_EXTENDED) - default recommended |
| i | Case-insensitive matching (REG_ICASE) |
| s | Report only success/fail (REG_NOSUB) |
| n | Newline-sensitive matching (REG_NEWLINE) |
Multiple flags can be combined, e.g., "ei" for extended and case-insensitive.
Scheme "first"** (default): Matches the pattern once and extracts capture groups
The variables created are:
Example with "first" scheme:
This creates variables:
hwdev2 = "0" (second capture group - device number)
Scheme "all"** [Syntax 9]: Matches the pattern multiple times and extracts all matches
The variables created are:
Example with "all" scheme:
This creates variables:
Extract USB device vendor and product IDs:
Parse multiple key=value pairs:
Extract text components:
Variables can be substituted using ${var:name} reference. For example, to use the extracted card number: PlaybackPCM "hw:${var:hwdev1},0"
Macros were added for Syntax version 6. The DefineMacro defines new macro like:
The arguments in the macro are refered as the variables with the double underscore name prefix (like __variable). The configuration block in the DefineMacro subtree is always evaluated (including arguments and variables) at the time of the instantiation. Argument string substitutions (for multiple macro call levels) were added in Syntax version 7.
The macros can be instantiated (expanded) using:
The second identifier (in example as id1) must be unique, but the contents is ignored. It just differentiate the items in the subtree (allowing multiple instances for one macro).
The configuration tree evaluation supports the conditions - If blocks. Each If blocks must define a Condition block and True or False blocks or both. The True or False blocks will be merged to the parent tree (where the If block is defined) when the Condition is evaluated.
Starting with Syntax version 8, If blocks can also include Prepend and Append configuration blocks. These blocks are always merged to the parent tree, independent of the condition evaluation result:
Example:
Example with Prepend and Append (Syntax version 8+):
Example with Prepend/Append only (no Condition, Syntax version 8+):
Execute only True block. It may be used to change the evaluation order as explained in the Configuration Tree paragraph.
| Field | Description |
|---|---|
| Empty | string |
| Field | Description |
|---|---|
| String1 | string |
| String2 | substring in string |
| Field | Description |
|---|---|
| Haystack | string |
| Needle | substring in string |
| Field | Description |
|---|---|
| String | string |
| Regex | regex expression (extended posix, ignore case) |
| Field | Description |
|---|---|
| Path | path (filename) |
| Mode | exist,read,write,exec |
Note: Substitution for Path and Mode fields were added in Syntax version 7.
| Field | Description |
|---|---|
| Device | ALSA control device (see snd_ctl_open()) |
| Control | control in ASCII (parsed using snd_ctl_ascii_elem_id_parse()) |
| ControlEnum | value for the enum control (optional) |
Example:
| Field | Description |
|---|---|
| Operation | comparison operator (==, !=, <, >, <=, >=) |
| Value1 | first integer value (string converted to long long) |
| Value2 | second integer value (string converted to long long) |
Note: Integer condition is supported in Syntax version 9+.
Example:
To avoid duplication of the many configuration files for the cases with minimal configuration changes, there is the variant extension. Variants were added for Syntax version 6.
The bellow example will create two verbs - "HiFi" and "HiFi 7.1" with the different playback channels (2 and 8) for the "Speaker" device.
Example (main configuration file):
Example (verb configuration file - HiFi.conf):
Starting with Syntax 8, devices can define variants using the DeviceVariant block. Device variants provide a convenient way to define multiple related devices with different configurations (such as different channel counts) in a single device definition.
When a device name contains a colon (':') character and the device configuration includes DeviceVariant* blocks, the UCM parser handles variant configuration in two ways:
Each variant device name is constructed by combining the base device name with the variant identifier. Variant devices are automatically added to the base device's conflicting device list, since these configurations are mutually exclusive (e.g., you cannot use 2.0, 5.1, and 7.1 speaker configurations simultaneously).
Example - Speaker with multiple channel configurations:
This configuration creates three UCM devices:
The variant devices (Speaker:5.1 and Speaker:7.1) inherit all configuration from the base device and override only the values specified in their DeviceVariant block. The devices are automatically marked as conflicting with each other.
Example - HDMI output with different sample rates:
This creates two devices: HDMI:LowRate (48kHz) and HDMI:HighRate (192kHz).
Starting with Syntax 9, the UCM configuration supports the Repeat block for generating repetitive configuration patterns. This feature allows you to apply a configuration block multiple times with different variable values, reducing duplication in configuration files.
The Repeat block contains two main components:
The Pattern block supports two types: Integer and Array.
Integer Pattern**: Iterates over a range of integer values
Fields for Integer pattern:
The iteration supports reverse order automatically when First is greater than Last.
Array Pattern**: Iterates over a list of string values
Fields for Array pattern:
Array: A compound node containing string values to iterate over
String Pattern**: Pattern can also be specified as a string that will be parsed as a configuration block. This allows for dynamic pattern generation.
Example using Integer pattern to create multiple similar control settings:
This generates 8 cset commands for channels 0 through 7.
Example using Array pattern for different device configurations:
This creates three SectionDevice blocks for Speaker, Headphones, and LineOut.
1.16.1