I don't understand snd_pcm_ops

I don't understand snd_pcm_ops

[Timur Tabi]

I'm new to ALSA driver development, and I'm writing an SOC driver for new hardware.  Can 
someone explain to me what the snd_pcm_ops structure is for?  And it sounds like a stupid 
question, but after studying documentation and sample code, I'm still confused.

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.

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???

Some background: I'm writing driver for a new SOC that has an I2S interface, and it's 
talking to a CS4270 codec, but the CS4270 codec is wired up in "stand-alone" mode, so 
there's no software configuration.

--
Timur Tabi
Linux Kernel Developer @ Freescale

Re: I don't understand snd_pcm_ops

[Ash Willis]

> 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

=

Re: I don't understand snd_pcm_ops

[Timur Tabi]

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?

-- 
Timur Tabi
Linux Kernel Developer @ Freescale