Introduction: DAPM (Dynamic Audio Power Management) is a power management mechanism specifically designed for the audio subsystem within the ALSA framework, aimed at reducing power consumption of audio devices by dynamically switching the power of audio components on and off. DAPM analyzes the dependencies of the audio path to automatically determine which components need to be turned on or off. For example, when headphones are plugged in, DAPM will activate all components on the headphone output path and deactivate the speaker path to save power. In the ALSA framework, the basic unit of DAPM is the widget, where each widget represents a controllable audio component, such as input ports (like microphones), output ports (like speakers), mixers, amplifiers, etc. Widgets are connected by paths, forming a network for audio signal transmission. DAPM divides the power management of the audio system into multiple power domains, such as codec domain, platform/machine domain, path domain, and stream domain. Each power domain corresponds to a dapm context and is responsible for managing the power state of widgets within that domain. DAPM uses dapm context to organize and manage widgets. Widgets belonging to the same component (such as codec, platform, or the entire sound card) are located within the same dapm context.1. Core Data Structures of DAPM1. struct snd_soc_jackstruct snd_soc_jack represents a Jack (socket) and works in conjunction with Jack Detection GPIO or the internal detection mechanism of the Codec to manage the connection status of the jack (such as plug insertion/removal) and the corresponding handling of these events, such as notifying the upper application through the input subsystem and triggering audio path switching in the kernel dapm mechanism.
pins:List of jack_pins associated with this jackstatus:Current status of the jack (bitmask, e.g., SND_JACK_HEADPHONE)2. struct snd_soc_jack_pinDescribes which DAPM endpoints (such as headphone output, microphone input) need to be enabled or disabled when the jack status (such as headphone insertion/removal) changes. For example, when a headphone insertion is detected, the system will automatically disable the speaker output and enable the headphone output path.ASoC allows multiple detection methods (such as GPIO interrupts, built-in detection in CODEC) to be integrated on a single physical jack, with snd_soc_jack_pin associating the jack (struct snd_soc_jack) and the detection logic.
pin:Indicates the name of the DAPM Pin to be controlled. It matches the name of a widget defined in the DAPM dependency graph, such as “Headphone Jack”, “Mic Jack”, etc.mask:A bitmask indicating when this pin will be activated based on detected jack types. For example: if mask = SND_JACK_HEADPHONE, this pin will only be enabled when headphones are detected in the jack. If mask = SND_JACK_MICROPHONE, it will only trigger when a microphone is detected.invert:Indicates the opposite operation, for example,if snd_soc_jack_report reports status as 0, it enables the corresponding pin, and when reporting 1, it disables the pin.list:Used to link pins on the same snd_soc_jack.3. struct snd_soc_dapm_routestruct snd_soc_dapm_route is a structure that the driver (such as Codec or Machine driver) requires the developer to explicitly define during the initialization phase to describe the expected connection relationships (i.e., signal routing) between audio components.
Here is a definition example
static const struct snd_soc_dapm_route my_audio_routes[] = { // Indicates connection from "Mic" to "Mix" { "Mix", NULL, "Mic" }, // From "Mix" to "ADC" { "ADC", NULL, "Mix" }, // From "DAC" to "Headphone" { "Headphone", NULL, "DAC" },};In fact, rk3588 uses the functionsnd_soc_of_parse_audio_routing(card, “rockchip,audio-routing”);
4. struct snd_soc_dapm_pathThe audio path typically includes multiple middleware (described using widgets), such as Mic → Mic Bias → PGA → Mixer → ADC → …, and the role of snd_soc_dapm_path is to:
- Record the connection relationship between two DAPM Widgets (who connects to whom or the data flow direction between two components)
- Record whether this path is “active” (i.e., whether there is a signal passing through)
- Record control conditions on the path (such as whether it is controlled by kcontrol switches)
- Act as a basic unit for graph algorithms during DAPM path calculations (powering up/down widgets)
snd_soc_dapm_path is dynamically created by the DAPM framework during the audio system initialization phase based on the definitions in snd_soc_dapm_route.5. struct snd_soc_dapm_widgetsnd_soc_dapm_widget is used to describe an “audio component” or “audio signal node”, such as microphones, headphones, ADCs, DACs, mixers, volume controls, input/output ports, etc.
The above example is defined in the rockchip_multicodecs.c of the rk3588 SDK6. struct snd_soc_dapm_contextServes as the resource for dapm power management context.2. DAPM Event Handling Process The state of DAPM endpoints can be triggered by external events, such as interrupts generated by internal circuits of the codec or jack GPIO interrupts. When developing drivers, developers need to actively call snd_soc_jack_report to handle events when related interrupts occur. The dapm mechanism will automatically manage the power of the audio link and will also report to user-space programs through the input subsystem (CONFIG_SND_JACK_INPUT_DEV must be enabled).Here is an analysis of the function snd_soc_jack_report:
When the jack status changes, it will trigger a GPIO interrupt or an interrupt generated by the internal detection circuit of the Codec. The rockchip 3588 uses a soft interrupt mechanism to callsnd_soc_jack_report, and here are the main tasks ofsnd_soc_jack_report:a). The functionsnd_soc_jack_report first determines which event triggered it. Here is an example from rockchip 3588, plug removal -> enter interrupt -> reportSND_JACK_HEADSET status as 0, at this time, the functionsnd_soc_jack_report willupdate the status of snd_soc_jack to disable (set status |= SND_JACK_HEADPHONE).
b). snd_soc_jack_reportiterates through all registered snd_soc_jack_pin, callingsnd_soc_dapm_enable_pin for pins that need to be enabled, otherwise callingsnd_soc_dapm_disable_pin to disable. These two functions do not immediately handle the power state but instead find the snd_soc_dapm_widget with the same name as snd_soc_jack_pin, callingdapm_mark_dirty to link it to the dapm_dirty list of the card, which will later be completed bysnd_soc_dapm_sync for actual power control.Here, __snd_soc_dapm_set_pin is the actual processing function for snd_soc_dapm_disable(enable)_pin.
If every path change immediately traverses all components and updates the power state, it would introduce unnecessary calculations and hardware operations (such as register reads/writes), especially during frequent path switches (like switching microphones during a call). Therefore, the DAPM subsystem delays processing through “dirty marking”, merging multiple changes into a single batch update.
The function dapm_widget_invalidate_input(output)_paths is actually handled by the following function, which traverses the paths related to the widget. If the currentconnectedstate and the status before triggering are inconsistent, it marks the widget related to this path asnode->endpoints[dir] = -1
c). Callssnd_soc_dapm_sync to actually handle power management.
snd_soc_dapm_sync is ultimately completed by the abovedapm_power_widgets to perform the actual power state switching.
d). Finally, the functionsnd_soc_jack_report will callsnd_jack_report to report the jack status change to user-space programs.
3. Construction of DAPM Audio Paths
The sound card constructs paths during the registration phase by parsing the statically registered data structures such as card->routes and card->widgets through the function snd_soc_bind_card. These paths are pre-established, and when events are triggered, it only needs to traverse the linked list and update the power states.
Follow me! Learn more about low-level audio driver technology!
Recommended Reading:ALSA Driver: Detailed Explanation of ALSA Kernel Buffer and Read/Write Pointer UpdatesALSA Driver: ASoC Perspective on the ALSA FrameworkEssential Knowledge for High-Concurrency Audio: Detailed Explanation of ALSA fasync Asynchronous MechanismALSA Driver: ALSA Framework from the Device Driver PerspectiveALSA Driver: Analysis of Audio Control Component Software Framework