SNDRV_PCM_INFO_MMAP - what do I need for it?

SNDRV_PCM_INFO_MMAP - what do I need for it?

[Timur Tabi]

My 8610 ASoC driver has this:

static const struct snd_pcm_hardware fsl_dma_hardware = {

	.info   		= SNDRV_PCM_INFO_INTERLEAVED,

This means that MMAP is not enabled.

I understand what MMAP is, but not from an ALSA driver perspective.  If I change 
the above line to this:

	.info   		= SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_MMAP | 
SNDRV_PCM_INFO_MMAP_VALID,

what does ALSA do differently?  Do I need to define any new functions?  From an 
application perspective, what is different?

Also, does DMIX need MMAP support?

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: SNDRV_PCM_INFO_MMAP - what do I need for it?

[Takashi Iwai]

At Wed, 16 Jan 2008 09:17:57 -0600,
Timur Tabi wrote:
> 
> My 8610 ASoC driver has this:
> 
> static const struct snd_pcm_hardware fsl_dma_hardware = {
> 
> 	.info   		= SNDRV_PCM_INFO_INTERLEAVED,
> 
> This means that MMAP is not enabled.
> 
> I understand what MMAP is, but not from an ALSA driver perspective.  If I change 
> the above line to this:
> 
> 	.info   		= SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_MMAP | 
> SNDRV_PCM_INFO_MMAP_VALID,
> 
> what does ALSA do differently?  Do I need to define any new functions?  From an 
> application perspective, what is different?

It means that the driver supports mmap access to the PCM buffer.

In some cases, you need to implement a proper mmap callback.  For
example, when the coheret (dma) pages are allocated via
dma_alloc_coherent and used for the PCM buffer, you need mmap callback
for ARM, at least because the default mmap handler in the PCM core
doesn't work for ARM.  In this case, prepare your own mmap callback
and pass it to pcm ops.  It should call simply dma_mmap_coherent()
appropriately.


> Also, does DMIX need MMAP support?

Yes, mandatory.


Takashi

Re: SNDRV_PCM_INFO_MMAP - what do I need for it?

[Timur Tabi]

Takashi Iwai wrote:
> At Wed, 16 Jan 2008 09:17:57 -0600,
> Timur Tabi wrote:
>> My 8610 ASoC driver has this:
>>
>> static const struct snd_pcm_hardware fsl_dma_hardware = {
>>
>> 	.info   		= SNDRV_PCM_INFO_INTERLEAVED,
>>
>> This means that MMAP is not enabled.
>>
>> I understand what MMAP is, but not from an ALSA driver perspective.  If I change 
>> the above line to this:
>>
>> 	.info   		= SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_MMAP | 
>> SNDRV_PCM_INFO_MMAP_VALID,
>>
>> what does ALSA do differently?  Do I need to define any new functions?  From an 
>> application perspective, what is different?
> 
> It means that the driver supports mmap access to the PCM buffer.
> 
> In some cases, you need to implement a proper mmap callback.  For
> example, when the coheret (dma) pages are allocated via
> dma_alloc_coherent and used for the PCM buffer, you need mmap callback
> for ARM, at least because the default mmap handler in the PCM core
> doesn't work for ARM.  In this case, prepare your own mmap callback
> and pass it to pcm ops.  It should call simply dma_mmap_coherent()
> appropriately.

The default mmap handler in the PCM core is snd_pcm_default_mmap()?

How can I know whether this function works?  Can I just add those two flags to 
my .info line, and then .... ?  Is there an ALSA mmap test utility?

>> Also, does DMIX need MMAP support?
> 
> Yes, mandatory.

So just to be clear: the fact that I do *not* have "SNDRV_PCM_INFO_MMAP | 
SNDRV_PCM_INFO_MMAP_VALID" defined in snd_pcm_hardware.info is the reason why I 
get this error message:

root@MPC8610HPCD:/home/demo_files/mp3# alsaplayer -o alsa -q -F 48000
-d plug:dmix ./527182737.mp3 &
[1] 3224
root@MPC8610HPCD:/home/demo_files/mp3# ALSA lib
pcm_direct.c:874:(snd_pcm_direct_initialize_slave) slave plugin does not
support mmap interleaved or mmap noninterleaved access
ALSA lib pcm_dmix.c:878:(snd_pcm_dmix_open) unable to initialize slave
snd_pcm_open: Invalid argument (plug:dmix)
Failed to initialize plugin!
...

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: SNDRV_PCM_INFO_MMAP - what do I need for it?

[Timur Tabi]

Timur Tabi wrote:

> How can I know whether this function works?  Can I just add those two flags to 
> my .info line, and then .... ?  Is there an ALSA mmap test utility?

Ok, I think aplay can do this.

I ran this command:

aplay -Dhw:0,0 -f S16_BE -M -r 48000 -c 2 15.raw

and I got this error:

aplay: set_params:852: Access type not available

so I modified my .info line and added those two macros.  When I run "aplay -M", 
it plays the file fine.

Does this mean that my one-line change has added mmap support to my driver, and 
dmix should now work?

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: SNDRV_PCM_INFO_MMAP - what do I need for it?

[Trent Piepho]

On Wed, 16 Jan 2008, Timur Tabi wrote:
> Takashi Iwai wrote:
> > At Wed, 16 Jan 2008 09:17:57 -0600,
> > Timur Tabi wrote:
> >> 	.info   		= SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_MMAP |
> >> SNDRV_PCM_INFO_MMAP_VALID,
> >>
> >> what does ALSA do differently?  Do I need to define any new functions?  From an
> >> application perspective, what is different?
> >
> > It means that the driver supports mmap access to the PCM buffer.
> >
> > In some cases, you need to implement a proper mmap callback.  For
> > example, when the coheret (dma) pages are allocated via
> > dma_alloc_coherent and used for the PCM buffer, you need mmap callback
> > for ARM, at least because the default mmap handler in the PCM core
> > doesn't work for ARM.  In this case, prepare your own mmap callback
> > and pass it to pcm ops.  It should call simply dma_mmap_coherent()
> > appropriately.
>
> The default mmap handler in the PCM core is snd_pcm_default_mmap()?
>
> How can I know whether this function works?  Can I just add those two flags to
> my .info line, and then .... ?  Is there an ALSA mmap test utility?

You can use the -M option with arecord and aplay too see if mmap works.
You need to actually hear/record sound to know, just getting no errors
isn't enough.

The default mmap hander will work if you used ALSA to allocate the DMA
buffer.  If you didn't, for example the cx88-alsa and bt87x drivers use
vmalloc(), then you need to write your own mmap handler.  The handler I
wrote for the previously mentioned drivers wasn't complex.