[alsa-devel] [PATCH 3/7] ALSA: pcm: avoid mmap of control data if .update_appl_ptr is implemented

Subhransu S. Prusty subhransu.s.prusty at intel.com
Mon Oct 3 06:43:22 CEST 2016


On Fri, Sep 30, 2016 at 03:40:45PM +0200, Takashi Iwai wrote:
> On Fri, 30 Sep 2016 14:43:26 +0200,
> Subhransu S. Prusty wrote:
> > 
> > From: Ramesh Babu <ramesh.babu at intel.com>
> > 
> > In case of mmap, by default alsa-lib mmaps both control & status data.
> > 
> > If driver subscribes for .appl_ptr_update, driver needs to get
> > notification whenever appl ptr changes. So with control & status mmaped,
> > driver won't get appl ptr notifications.
> > 
> > In alsa-lib IOCTL_SYNC_PTR can be forced using  sync_ptr_ioctl flag in
> > conf But this makes driver behavior dependent on a flag in the conf.
> > 
> > This patch conditionally checks for .appl_ptr_update and returns error
> > when user land asks for mmaping control & status data, thus forcing user
> > to issue IOCTL_SYNC_PTR.
> > 
> > One drawback with this approach is, if .appl_ptr_update is subscribed by
> > driver, the user space looses flexibility to mmap the control & status
> > data.
> 
> Yes, and it can be seen as an obvious regression, so I'm not sure
> whether this condition is the best choice.
> 
> OTOH, I now understand why you need it in this way -- alsa-lib does
> mmap ctrl/status pages at snd_pcm_open() and sync_ptr is used only as
> a fallback.  So, one solution would be to fix alsa-lib side.  Or, if
> we fix the kernel in this way, it would work with old alsa-lib, but it
> has another penalty.  Hmm...

I will check if it can be fixed in alsa-lib side.

Regards,
Subhransu
> 
> 

-- 


More information about the Alsa-devel mailing list