Lines Matching +full:audio +full:- +full:core

2 Dynamic Audio Power Management for Portable Devices
8 Dynamic Audio Power Management (DAPM) is designed to allow portable
9 Linux devices to use the minimum amount of power within the audio
11 such, can easily co-exist with the other PM systems.
14 all power switching is done within the ASoC core. No code changes or
16 switching decisions based upon any audio stream (capture/playback)
17 activity and audio mixer settings within the device.
20 audio subsystem, this includes internal codec power blocks and machine
26 VREF, VMID (core codec and audio power)
39 audio subsystem signal paths
50 All DAPM power switching decisions are made automatically by consulting an audio
52 consists of the interconnections between every audio component (including
53 internal codec components). All audio components that effect power are called
60 Audio DAPM widgets fall into a number of types:-
89 External regulator that supplies power to audio components.
91 External clock that supplies clock to audio components.
93 Audio Interface Input (with TDM slot mask).
95 Audio Interface Output (with TDM slot mask).
99 Digital Audio Interface Input.
101 Digital Audio Interface Output.
109 Inter widget audio data buffer within a DSP.
114 Widget that performs an audio processing effect.
120 Widget that encodes audio data from one format (usually PCM) to another
123 Widget that decodes audio data from a compressed format to an
127 (Widgets are defined in include/sound/soc-dapm.h)
130 There are convenience macros defined in soc-dapm.h that can be used to quickly
138 ---------------------
144 Stream widgets have the following format:-
167 -------------------
169 Path domain widgets have a ability to control or affect the audio signal or
170 audio paths within the audio subsystem. They have the following form:-
196 ----------------------
200 machine audio component (non codec or DSP) that can be independently
210 when the Mic is inserted:-::
222 -------------------
230 ---------------
232 Sometimes widgets exist in the codec or machine audio map that don't have any
234 a virtual widget - a widget with no control bits e.g.
249 audio paths (called interconnections). Each interconnection must be defined in
250 order to create a map of all audio paths between widgets.
253 audio system), as it requires joining widgets together via their audio signal
266 connect the destination widget (wrt audio signal) with its source widgets.
274 So we have :-
283 Interconnections are created with a call to:-
289 interconnections have been registered with the core. This causes the core to
295 -------------------------------
312 An endpoint is a start or end point (widget) of an audio signal within the
329 Some widgets can register their interest with the DAPM core in PM events.
345 Please see soc-dapm.h for all other widgets that support events.
349 -----------
359 #define SND_SOC_DAPM_PRE_REG 0x10 /* before audio path setup */
360 #define SND_SOC_DAPM_POST_REG 0x20 /* after audio path setup */