Use Case Manager

From AlsaProject
Revision as of 09:13, 3 August 2012 by Tanuk2 (Talk | contribs)

Jump to: navigation, search

ALSA Use Case Manager (UCM) allows applications to access the hardware in an abstracted manner so that the applications don't need to be tailored for each hardware product separately. The system is designed especially for embedded systems, where the amount of different mixer controls for routing and volume is massive. The idea is that an application tells UCM that it needs to do e.g. voice call, and UCM then takes care of adjusting the mixer controls appropriately. UCM also tells the application which PCM device to use and how to do volume control for that use case.

In order to set up the mixer controls right, UCM needs to have configuration files written for the hardware. So, writing ALSA configuration for different hardware products can't be avoided, but instead of each application doing it themselves, the configuration can be written only once, and used by all applications.

Comment: True application portability would require standardizing the UCM identifiers, and AFAIK, that has not been done so far. Tanuk2 (talk) 16:02, 2 August 2012 (CEST)


Cards, Verbs, Devices and Modifiers

UCM configuration is written for each card separately, so card is the top level object in the hierarchy.

Cards have "verbs", sometimes also called "use cases". I'm not convinced that the verb concept makes sense, so I'll ignore the concept by defining only one verb for each card. (The expected thing to do would be to define verbs like "HiFi", "HiFi Low Power", "Voice" etc., but as a PulseAudio developer, I don't see that as a useful way of describing the hardware.)

Each verb can have "devices" (speakers, headphones etc.) and "modifiers" (these seem to be like "more detailed use cases than verbs", e.g. "Capture Voice", "Capture Music", "Play Voice" etc.). Again, I don't find the modifier concept useful, so I'll ignore it. All I really want is a list of available devices and enough information about the devices to do routing decisions in PulseAudio (or maybe in some external routing policy system on top of PulseAudio). So, the configuration that I'll write will concentrate on devices only, not on verbs or modifiers.

UCM Configuration Files

The UCM configuration files are installed by default in /usr/share/alsa/ucm/. That directory contains a subdirectory for every sound card that has UCM configuration written for it, and each subdirectory contains a card configuration file with the directory name plus ".conf" suffix. For example, the card configuration file for RX-51 (the sound card in Nokia N900) would be located at /usr/share/alsa/ucm/RX-51/RX-51.conf. The card configuration file references verb configuration files in the same directory.

The Card Configuration File

The card configuration file can have one or more sections for the verbs, and an optional section for initializing the card to default values.



SectionUseCase."Verb Name" {
        File "Verb_Name.conf"
        Comment "Here's a comment describing Verb Name"

Here "use case" means verb. Why is it not "SectionVerb", then? Probably because SectionVerb is a keyword that is reserved for a different purpose (see the section on verb configuration files). So, the section tells that this card has a verb called "Verb Name", and the configuration details for it can be found in file Verb_Name.conf in the same directory. The optional Comment field can be used to describe the verb, and the comment will be available to applications through the UCM API.

Example from the N900 configuration that I'm writing:

SectionUseCase."Nokia N900" {
        File "Nokia_N900.conf"

Since I want to have only one verb, coming up with a name was a bit tricky, because the verb doesn't have any meaning in itself. I chose "Nokia N900", because it results in a nice file name that says very clearly that "here you can find the UCM configuration for the Nokia N900".



SectionDefaults [
        cdev "hw:FooCard"
        cset "name='Bar Playback Volume' 0"

SectionDefaults defines what should be done when resetting the card to its default state. The sequence of commands is executed when the use case manager is opened (snd_use_case_mgr_open()), reloaded (snd_use_case_mgr_reload()) or reset (snd_use_case_mgr_reset()), and also when setting the current verb with snd_use_case_set().

Custom Search
Personal tools