From bottom to top, they are ALSA driver, ALSA Lib, and ALSA application:
ALSA applications include aplay and arecord. They are ALSA utils tools. These tools are very good for testing drivers.
ALSA lib provides function libraries for enabling, disabling, and playing.
The ALSA driver was later added with support for SOC, and abstracted the control of hardware audio codec and put it in the directory of sound/soc/codecs. The Code related to the SoC hardware is abstracted and stored in the OMAP directory (added to the SOC is OMAP ). This separation design allows a codec code to correspond to a lot of SOC without any modification.
One of the big guys in ALSA's SOC is dapm (Dynamic Audio Power Management), which divides the power supply into four domains:
1 codec domain-vref, vmid (core codec and audio power) usually controlled at codec probe/remove and suspend/resume, although can be set at stream time if power is not needed for sidetone, etc.
2 platform/machine domain-physically connected inputs and outputs is platform/machine and user action specific, is configured by the machine driver and responds to asynchronous events e. g when HP are inserted.
3 path domain-audio susbsystem Signal paths. automatically set when
Mixer and MUX settings are changed by the user. e.g. alsamixer, amixer.
4 stream domain-DACS and ADCs. enabled and disabled when stream playback/capture is started and stopped respectively. e.g. aplay, arecord.
For codec domain, it is located in the sound/soc/codecs directory, for example, wm9713.c.
For platform/machine domain, it is placed in the machine name directory, for example, neo1973_wm9753.c under the sound/soc/s3c24xx directory. The name is the same as the machine name and CODEC name.
When defining the audio path of codec, you need to know the background knowledge. dapm is divided into the following parts in concept:
- Mixer-mixes several analog signals into a single analog signal. Hybrid
- MUX-an analog switch that outputs only one of your inputs. Switch
- PGA-A Programmable Gain Amplifier or attenuation widget. Programmable Gain margin or attenuation part
- ADC-analog to digital converter
- DAC-digital to Analog Converter
- Switch-an analog switch
- Input-A codec Input Pin
- Output-A codec output pin
- Headphone-headphone (and optional Jack) headphones
- Mic-mic (and optional Jack)
- Line-line input/output (and optional Jack)
- Speaker-speaker
- Pre-special pre widget (Exec before all others)
- Post-special post widget (Exec after all others)
For the start endpoint input on the path, it only needs to output to the next part. Similarly, for the output endpoint on the path, it only needs to input from the previous part. Snd_soc_dapm_input or snd_soc_dapm_output is used to define the header and end endpoint of path. There is a mix in codec. It always adds multiple inputs to an output signal, which is defined by snd_soc_dapm_mixer. In codec, there are also some multiline switches, which have multiple inputs, but only one input can be connected to the output. Such components are defined by snd_soc_dapm_mux. PGA is like its name in hardware. It is generally an input and an output. It is defined by snd_soc_dapm_pga. Audio
Codec has many components and can be any name. How can ALSA know how to operate these components to switch to the desired path? in real time, ALSA lib does not care about this part, these minor switches are completed by ALSA application and above. ALSA lib also provides a maximum of mixer or MUX function operations. If the switchover is your application.
The part operation function is snd_mixer_selem_set_enum_item (). alsamixer also uses this function to achieve switching.
Certificate --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1. SOC audio driver module
Register a driver named "Soc-Audio" soc_driver
Platform_driver_register (soc_driver)
Static struct platform_driverSoc_driver= {
. Driver = {
. Name ="Soc-Audio",
},
. Probe =Soc_probe,
. Remove = soc_remove,
. Suspend = soc_suspend,
. Resume = soc_resume,
};
Soc_driverThe main function is soc_probe (). This function is mainly used to obtain the device struct.
Struct snd_soc_device. then execute the probe () function of some members (snd_soc_machine, snd_soc_platform, soc_codec_device) in this struct to mount the driver.
Static int soc_probe (struct platform_device * pdev)
{
Struct snd_soc_device *Socdev= Platform_get_drvdata (pdev );
Struct snd_soc_machine * Machine = socdev-> machine;
Struct snd_soc_platform * platform = socdev-> platform;
Struct snd_soc_codec_device * codec_dev = socdev-> codec_dev;
Machine-> probe (pdev );
Platform-> probe (pdev );
Codec_dev-> probe (pdev );
......
}
2. SOC audio device module
This part involves the IIS or ac97 audio interface, PCM Interface, and the corresponding Codec Chip interface. IIS, ac97, and PCM files are all in the sound/soc/s3c24xx/folder, and the codec chip interface file is in the sound/soc/codecs folder.
These interface declarations are in the include/sound/soc. h file, and finally are in the device struct.
In snd_soc_device, struct snd_soc_device is defined as follows:
/* SOC device-the Audio Subsystem */
Struct snd_soc_device {
Struct device * dev;
Struct snd_soc_machine * machine;
Struct snd_soc_platform * platform;
Struct snd_soc_codec * codec;
Struct snd_soc_codec_device * codec_dev;
Struct delayed_work;
Void * codec_data;
};
To compile an audio driver, you need to create a platfomr_device named "Soc-Audio" and use the platform_set_drvdata function to define the struct.
Set snd_soc_device to private data of the device driver.
3. SOC audio driver files
The following describes the content and purpose of several main files in each folder.
Sound/soc/soc-core.c
[Module]
Register the driver stuct
Platform_driver soc_driver {...}; some common functions such as PCM are also export.
Sound/soc/s3c24xx/s3c24xx-i2s.c
Export interface struct
Struct snd_soc_cpu_dai s3c24xx_i2s_dai = {...} is mainly used for setting and controlling IIS interfaces.
Sound/soc/s3c24xx/s3c24xx-pcm.c
Export interface struct
Snd_soc_platform s3c24xx_soc_platform = {...}, mainly PCM operations.
Files to be compiled:
Sound/soc/codecs/xxx. c XXX. h
Define struct snd_soc_codec_dai
And struct snd_soc_codec_device
Sound/soc/s3c24xx/chipxxx_codecxxx.c [module]
Create a device struct snd_soc_device s3c2410_snd_devdata using the interface in the preceding file, and create and register a device named "Soc-Audio": struct
Platform_device, note that you need to call the platform_set_drvdata function to define the struct
Set snd_soc_device to private data of the device driver.