[alsa-devel] clarification on mmap

[Takashi Iwai]

At Tue, 24 Feb 2009 13:15:53 +0530,
Harsha, Priya wrote:
> 
> The exact issue I am facing is - if the data is mmaped or not I
> would want to know that the dma_area is filled and how much is
> filled so that I can setup the dma to transfer it to the hardware.
> 
> Can you suggest a way to do this?
> 
> Will the following help?
> 
> 1. If the data is not mmaped, can I setup the transfer in .ack call
> to transfer the data copied from dma_area to hardware? 
> 2. If the data is mmaped; In the .pointer call back, I get the exact
> hw pointer of how much has been played out. Here can I setup another
> transfer from dma_area? 
> 3. How can I know internally in the driver if the application has
> mmaped the buffer or using the method of sending user buffers? 

Well, before going further into your questions, let's make the
hardware design ALSA PCM framework assumes.

First off, the hardware is supposed to transfer the data from the
given buffer (RAM) to the hardware in the background (e.g. DMA).
Usually, the driver sets up the transfer in prepare callback, give a
go at trigger callback, then the hardware will keep feeding the data
from the given ring-buffer to the hardware continuously without any
action.

The driver sets up the "period".  It's the time the driver is woken
up, and usually triggered by a hardware IRQ.  The ISR will then call
snd_pcm_period_elapsed() so that PCM core will work the rest of the
job (updating hwptr, waking up the sleepers, etc).  Meanwhile, PCM
core will ask the driver to return the current transfer position in
the ring buffer via pointer callback.  The driver is responsible for
that.

That's all.  In this implementation case, there is no difference
between the RW and the mmap transfers.  The difference is handled in
the PCM core.

Note that there is no need to refer to appl_ptr in the driver side
because the DMA transfer is done continuously in the ring buffer.

If your hardware behaves differently, there need some workarounds to
adapt that.  For example, usb-audio has an intermediate buffer to
handle URBs continuously.

If you need to feed the sample data to the hardware manually, e.g. via
loop, the above model doesn't work because the (mmapped) data can be
written at any moment on the ring buffer.  You can fake it, but it's
not that perfect.

Now, please make clear how your hardware works, and what is required
in addition to that...


Takashi

> 
> Thanks,
> Harsha
> 
> 
> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai at suse.de] 
> Sent: Tuesday, February 24, 2009 12:16 PM
> To: Harsha, Priya
> Cc: alsa-devel at alsa-project.org
> Subject: Re: clarification on mmap
> 
> At Tue, 24 Feb 2009 10:24:19 +0530,
> Harsha, Priya wrote:
> > 
> > Thanks Takashi. Then what would be the best way to know when the
> > mmaped buffer has been filled. So that I can take action to send it
> > to the hardware? 
> 
> In the current ALSA design, mmap transfer is completely asynchronous.
> The driver doesn't take care when app_ptr is updated.  It's checked
> only when the hw_ptr is updated in snd_pcm_period_elapsed().  So, in
> general, what the card driver needs is to provide the ISR calling
> snd_pcm_period_elapsed() appropriately and, if possible, to provide
> the accurate PCM pointer callback to give the updated hw_ptr.
> 
> In mmap mode, other any transfer to the hardware is supposed to be
> done by the hardware (DMA) more or less automatically.  If you need to
> do it by yourself, mmap isn't always the right answer.
> 
> > Should I use the runtime->control->appl_ptr or
> > runtime->status->appl_ptr to get the position the app has filled? 
> 
> appl_ptr exists only in runtime->control.
> 
> 
> HTH,
> 
> Takashi
> 
> > -----Original Message-----
> > From: Takashi Iwai [mailto:tiwai at suse.de] 
> > Sent: Tuesday, February 24, 2009 12:55 AM
> > To: Harsha, Priya
> > Cc: alsa-devel at alsa-project.org
> > Subject: Re: clarification on mmap
> > 
> > At Mon, 23 Feb 2009 22:21:24 +0530,
> > Harsha, Priya wrote:
> > > 
> > > Thank you. Can I use .ack callback to know that the mmaped buffer
> > > has been filled by the user?
> > 
> > Not really.  It's just for explicit read/write modes.
> > 
> > > How would I know how much the user has
> > > written into the buffer that time?
> > 
> > You can check appl_ptr at any time.  This corresponds to the position
> > the app has filled.
> > 
> > 
> > Takashi
> > 
> > > Would I need to have the pointers
> > > calculated and tracked myself or is there a field in the structures
> > > that I can read and find out? 
> > > 
> > > -----Original Message-----
> > > From: Takashi Iwai [mailto:tiwai at suse.de] 
> > > Sent: Monday, February 23, 2009 8:57 PM
> > > To: Harsha, Priya
> > > Cc: alsa-devel at alsa-project.org
> > > Subject: Re: clarification on mmap
> > > 
> > > At Mon, 23 Feb 2009 18:59:11 +0530,
> > > Harsha, Priya wrote:
> > > > 
> > > > Hi,
> > > > 
> > > > I have a question on mmap. If I give my .info to be _MMAP and
> > > > _MMAP_VALID. Will ALSA framework internally take care of mmap-ing
> > > > the kernel buffer that has been pre-allocated in the .probe call? Do
> > > > I need to do anything special to mmap a kernel buffer into user
> > > > space? Just accessing the runtime->dma_area would allow me to access
> > > > user data right? 
> > > 
> > > Yes.  The buffers allocated via preallocator are supposed to be
> > > mmappable, so you can simply pass _MMAP* flag there.
> > > 
> > > 
> > > Takashi
> > > 
> > 
>