[alsa-devel] snd_pcm_hardware_t.info question

Takashi Iwai tiwai at suse.de
Tue Apr 17 12:24:51 CEST 2007

At Tue, 17 Apr 2007 01:03:24 -0700 (PDT),
Ciaccia wrote:
> Hi all,
> I am trying to fix (improve?) a driver for an embedded
> ARM device I bought months ago, and for some reasons
> some ALSA applications work fine while other ones
> don't... 
> Looking at the driver I got, I noticed that the info
> field in the snd_pcm_hardware_t struct just defines:
> while the info in the tutorial "writing an alsa
> driver" defines: 
> Furthermore, the driver defines a copy callback
> (actually 2, one for playback and one for capture),
> where it copies the data from the use space to the dma
> buffer. Since the dma buffer was preallocated with
> snd_pcm_lib_preallocate_pages_for_all and is
> accessible from the "outside", I wonder why the
> original author did this...
> I have some questions for you gurus:
> - what is the difference between SNDRV_PCM_INFO_MMAP

MMAP flag is a very important flag.  This indicates that the driver
can work on mmap mode.  If not given, no mmap is allowed.

Meanwhile, MMAP_VALID and BLOCK_TRANSFER flags are only for kernel-OSS
emulation.  For ALSA native apps, they have no meaning.
MMAP_VALID is necessary for allowing OSS mmap mode.
BLOCK_TRANSFER is specified, it resets REALTIME capability in OSS

> - The code calls snd_pcm_lib_preallocate_pages_for_all
> function as following:
> /* allocate the pcm(DMA) memory */
> ret = snd_pcm_lib_preallocate_pages_for_all(pcm,
> SNDRV_DMA_TYPE_DEV,0, 4*128*1024, 4*128*1024);
> is the DMA_TYPE right for an ARM device? Is NULL a
> correct value for data in this case?

No, it should pass the device pointer there.
Also make sure that snd_pcm_lib_malloc() is actually used in hw_params
callback.  Otherwise, pre-allocation makes no sense.

> - In case I get rid of the copy callback, how do I
> specify the format of the stream? How does Where can I
> find an example for that?

The available formats are specified snd_pcm_hardware formats.
Then in prepare callback, you can get the specified format by the
application via runtime->format field.

I don't understand the rest question in the above.  But, note that
the copy callback isn't used at all in mmap mode.  The copy/silenece
callbacks are for read/write mode.  When the app mmaps the buffer, it
means that the buffer is directly accessible without read/write
calls.  So, it skips copy and silence callbacks.  If any copy
operation is needed, the driver itself has to do in some way, e.g. in
background task or in ack callback.



More information about the Alsa-devel mailing list