Linux audio alsa-uda134x driver documentation (over-view)

From: http://blog.chinaunix.net/uid-22917448-id-1765502.html

Preface

Currently, audio drivers commonly used in linux are in two forms: alsa
Oss
Alsa: it is now the main form of audio driver in linux and is compatible with simple oss.
Oss: past forms
The uda1341 on our board uses the alsa driver.
Alsa Overview:
Because we use an on-board system and an alsa soc system. Therefore, we will directly explain the alsa soc subsystem.

ALSA SoC Layer
System layer on ALSA board
====================

The overall project goal of the ALSA System on Chip (ASoC) layer is
Provide better ALSA support for embedded system-on-chip processors (e.g.
Pxa2xx, au1x00, iMX, etc) and portable audio codecs. Prior to the ASoC
Subsystem there was some support in the kernel for SoC audio, however it
Had some limitations :-
The overall project goal of the ALSA board system (ASoC) layer is to provide better ALSA support for SOC embedded processors and portable audio decoders. Prior to the ASoC subsystem, we had SoC audio support for the kernel, but those support had some limitations:
Codec drivers were often tightly coupled to the underlying SoC
CPU. This is not ideal and leads to code duplication-for example,
Linux had different wm8731 drivers for 4 different SoC platforms.
Decoder is often closely integrated with the underlying embedded processor. This is not idealistic, because it will lead to code duplication-for example, Linux has a different wm8731 driver for four different embedded platforms. (The ideal state is that we can only have one wm8731 driver code, which can correspond to four different processors, but as mentioned above, decoder-The wm8731 here is too tightly integrated with the underlying embedded processor to reuse the wm8731 driver code)

* There was no standard method to signal user initiated audio events (e.g.
Headphone/Mic insertion, Headphone/Mic detection after an insertion
Event). These are quite common events on portable devices and often require
Machine specific code to re-route audio, enable amps, etc., after such
Event.
There is no standard method to generate a signal for the user to initialize the audio event (that is, the headset/microphone insertion, the headset/microphone probing in response to the insertion event ). These are very common events on portable devices. after these events, you often need machine-related code to reset the audio path and enable the amplifier.

* Drivers tended to power up the entire codec when playing (or
Recording) audio. This is fine for a PC, but tends to waste a lot
Power on portable devices. There was also no support for saving
Power via changing codec oversampling rates, bias currents, etc.
During sound recording, the driver often opens the entire decoder. This is no problem for personal computers, but power is often wasted on portable devices. In addition, it does not support power saving by changing the decoder sampling rate and offset current.

ASoC Design
ASoC Design
==============

The ASoC layer is designed to address these issues and provide the following
Features :-
The ASoC layer is designed to solve these problems and provides the following features:

* Codec independence. Allows reuse of codec drivers on other platforms
And machines.
The decoder is independent. Decoder drivers can be reused on other platforms or machines.

* Easy I2S/PCM audio interface setup between codec and SOC. Each SOC
Interface and CODEC registers it's audio interface capabilities with
Core and are subsequently matched and configured when the application
Hardware parameters are known.
It is easy to set the I2S/PCM audio interface between the decoder and SOC. Each SoC Interface and decoder register its audio interface capabilities with the Alsa core, and the application hardware parameters are matched and configured in a time-based sequence.

* Dynamic Audio Power Management (dapm). dapm automatically sets the CODEC
Its minimum power state at all times. This includes des powering up/down
Internal power blocks depending on the internal codec audio routing and any
Active streams.
Dynamic Audio Power Management (dapm ). Dapm automatically sets the decoder to its minimum power status at any time. This includes enabling and disabling the internal power supply module based on the internal Decoding of audio channels and active streams.

* Pop and click functions. Pops and clicks can be forced ced by powering
Codec up/down in the correct sequence (including using digital mute). ASoC
Signals the codec when to change power states.
Click to decrease. The click sound can be reduced by using the correct decoder power-on and off sequence (including using digital music ). ASoC sends a signal to the decoder when the power status changes.

* Machine specific controls: Allow machines to add controls to the sound card
(E.g. volume control for speaker amplifier ).
Machine-related control: allows the machine to add control over the sound card. (For example, the volume control of the speaker amplifier ).

To achieve all this, ASoC basically splits an embedded audio system into 3
Components :-
To achieve this, ASoC basically divides the embedded audio system into three parts:

* Codec driver: The codec driver is platform independent and contains audio
Controls, audio interface capabilities, codec DAPM definition and codec IO
Functions.
Decoder driver: the decoder driver is platform-independent and includes audio control, audio interface capabilities, decoder Dynamic Audio Power Management, and decoder I/O functions.

* Platform driver: The platform driver contains the audio DMA engine and audio
Interface drivers (e.g. I2S, AC97, PCM) for that platform.
Platform DRIVER: the platform driver includes the audio DAM engine and audio interface driver of the corresponding platform (such as I2S, AC97, PCM)

* Machine driver: The machine driver handles any machine specific controls and
Audio events (e.g. turning on an amp at start of playback ).
Machine driver: The machine driver processes control and Audio events related to all machines (for example, enable the amplifier at the start of playback ).

Documentation
Document
==================

The documentation is spilt into the following sewing :-
This document is divided into the following parts:

Overview.txt: This file.
Overview.txt: Overview, this file.
Codec.txt: Codec driver internals.
Codec.txt: internal implementation of decoder driver

DAI.txt: Description of Digital Audio Interface standards and how to configure
A DAI within your codec and cpu dai drivers.
DAI.txt: A description of the digital audio interface in the digital audio interface (DAI) standard and how to configure your decoder and CPU Digital Audio connector driver.

Dapm.txt: Dynamic Audio Power Management
Dapm.txt: Dynamic Audio Power Management

Platform.txt: Platform audio DMA and DAI.
Platform.txt: Platform audio DMA and DAI.

Machine.txt: Machine driver internals.
Machine.txt: Machine driver description.

Pop_clicks.txt: How to minimize audio artifacts.
Pop_clicks.txt: how to minimize the sound step noise.

Clocking.txt: ASoC clocking for best power performance.
Clocking.txt: ASoC clock for optimal power supply performance

See: http://www.junziju.usr.cc/home/space.php? Uid = 2 & do = blog & id = 327 gentleman note:
What you are reading now is the document translation written by the gentleman when reading the Linux audio SoC driver.
The gentleman writes some translations. On the one hand, it serves as his own notes to help his memory, and on the other hand, he hopes to help others.
If you are able to get something from the gentleman's translation, I am very pleased.
All the original documents are all in the linux-2.6.30/Documentation/sound/alsa/soc directory.
Since the gentleman does not know much about the audio content, I do not understand it in many places, but just translated it in the original article.
Here, the guests who are willing to visit are not necessarily correct.
Zhang Jun again.