| rjw | 1f88458 | 2022-01-06 17:20:42 +0800 | [diff] [blame^] | 1 | ======================= |
| 2 | ALSA SoC Layer Overview |
| 3 | ======================= |
| 4 | |
| 5 | The overall project goal of the ALSA System on Chip (ASoC) layer is to |
| 6 | provide better ALSA support for embedded system-on-chip processors (e.g. |
| 7 | pxa2xx, au1x00, iMX, etc) and portable audio codecs. Prior to the ASoC |
| 8 | subsystem there was some support in the kernel for SoC audio, however it |
| 9 | had some limitations:- |
| 10 | |
| 11 | * Codec drivers were often tightly coupled to the underlying SoC |
| 12 | CPU. This is not ideal and leads to code duplication - for example, |
| 13 | Linux had different wm8731 drivers for 4 different SoC platforms. |
| 14 | |
| 15 | * There was no standard method to signal user initiated audio events (e.g. |
| 16 | Headphone/Mic insertion, Headphone/Mic detection after an insertion |
| 17 | event). These are quite common events on portable devices and often require |
| 18 | machine specific code to re-route audio, enable amps, etc., after such an |
| 19 | event. |
| 20 | |
| 21 | * Drivers tended to power up the entire codec when playing (or |
| 22 | recording) audio. This is fine for a PC, but tends to waste a lot of |
| 23 | power on portable devices. There was also no support for saving |
| 24 | power via changing codec oversampling rates, bias currents, etc. |
| 25 | |
| 26 | |
| 27 | ASoC Design |
| 28 | =========== |
| 29 | |
| 30 | The ASoC layer is designed to address these issues and provide the following |
| 31 | features :- |
| 32 | |
| 33 | * Codec independence. Allows reuse of codec drivers on other platforms |
| 34 | and machines. |
| 35 | |
| 36 | * Easy I2S/PCM audio interface setup between codec and SoC. Each SoC |
| 37 | interface and codec registers its audio interface capabilities with the |
| 38 | core and are subsequently matched and configured when the application |
| 39 | hardware parameters are known. |
| 40 | |
| 41 | * Dynamic Audio Power Management (DAPM). DAPM automatically sets the codec to |
| 42 | its minimum power state at all times. This includes powering up/down |
| 43 | internal power blocks depending on the internal codec audio routing and any |
| 44 | active streams. |
| 45 | |
| 46 | * Pop and click reduction. Pops and clicks can be reduced by powering the |
| 47 | codec up/down in the correct sequence (including using digital mute). ASoC |
| 48 | signals the codec when to change power states. |
| 49 | |
| 50 | * Machine specific controls: Allow machines to add controls to the sound card |
| 51 | (e.g. volume control for speaker amplifier). |
| 52 | |
| 53 | To achieve all this, ASoC basically splits an embedded audio system into |
| 54 | multiple re-usable component drivers :- |
| 55 | |
| 56 | * Codec class drivers: The codec class driver is platform independent and |
| 57 | contains audio controls, audio interface capabilities, codec DAPM |
| 58 | definition and codec IO functions. This class extends to BT, FM and MODEM |
| 59 | ICs if required. Codec class drivers should be generic code that can run |
| 60 | on any architecture and machine. |
| 61 | |
| 62 | * Platform class drivers: The platform class driver includes the audio DMA |
| 63 | engine driver, digital audio interface (DAI) drivers (e.g. I2S, AC97, PCM) |
| 64 | and any audio DSP drivers for that platform. |
| 65 | |
| 66 | * Machine class driver: The machine driver class acts as the glue that |
| 67 | describes and binds the other component drivers together to form an ALSA |
| 68 | "sound card device". It handles any machine specific controls and |
| 69 | machine level audio events (e.g. turning on an amp at start of playback). |