Re: [alsa-devel] I don't understand snd_pcm_ops
First off, I thought PCM stood for Pulse Code Modulation, but that just describes the format of the digital data. I don't understand what a PCM operation could be.
Exactly, it described the format of the digital data used i audio processing. PCM does stand for pulse code modulation, but here it is a reference to a device that processes sample based digital audio i.e not midi etc.
The ALSA middle layer (which includes PCM) takes care of all the common stuff that all drivers need to do. In sound drivers, we have multiple types of devices: PCM, midi, mixers etc. The PCM layer is responsible for doing all the digital audio work. I.e preparing the card for playback, initiaing transfer to and from the device etc. In short, if you want to playback or capture sound, you're going to need a PCM :)
snd_pcm_ops is a structure of callbacks that relate to different events regarding the PCM interface. Use this to run your own code at specific events. I.e. it's most probable that you'll want to prepare the device in some manner before audio transfer starts, so you would put the code to do this into your prepare callback.
I've seen documentation where PCM is considered an alternative to I2S or AC97. But if you look at eti_b1_wm8731.c, you'll see this:
#include "at91-pcm.h" #include "at91-i2s.h"
So is the AT91 a PCM device or an I2S device???
None of these are alternatives to each other. They're all different things. The anser to your question would be that this is an i2c device that has a PCM.
Have you read "Writing an ALSA driver"? It generally describes ALSA drivers as they relate to PCI, and how to write them, but it does a good job at explaining the general ALSA driver architecture.
Ash
=
Ash Willis wrote:
Have you read "Writing an ALSA driver"? It generally describes ALSA drivers as they relate to PCI, and how to write them, but it does a good job at explaining the general ALSA driver architecture.
Unfortunately, most of my confusion stems from ASoC-specific issues. For instance, that document says I should call snd_pcm_new(). But that's not true for ASoC drivers, because I should really call snd_soc_new_pcms(), which in turn calls soc_new_pcm(), and *that* function calls snd_pcm_new(). However, none of that explains why it's the *codec* driver that is calling these functions. I don't understand why the codec driver is registering new PCMs. Shouldn't the PCM driver be registering the codec?
participants (2)
-
Ash Willis
-
Timur Tabi