Re: [PATCH v2 1/3] ALSA: pcm: Add the explicit appl_ptr sync support

[Takashi Iwai <tiwai@suse.de>]

On Fri, 23 Jun 2017 10:07:50 +0200,
Takashi Sakamoto wrote:
> 
> Hi,
> 
> On Jun 22 2017 00:31, Takashi Iwai wrote:
> > Currently x86 platforms use the PCM status/control mmaps for
> > transferring the PCM status and appl_ptr between kernel and
> > user-spaces.  The mmap is a most efficient way of communication, but
> > it has a drawback per its nature, namely, it can't notify the change
> > explicitly to kernel.
> >
> > The lack of appl_ptr update notification is a problem on a few
> > existing drivers, but it's mostly a small issue and negligible.
> > However, a new type of driver that uses DSP for a deep buffer
> > management requires the exact position of appl_ptr for calculating the
> > buffer prefetch size, and the asynchronous appl_ptr update between
> > kernel and user-spaces becomes a significant problem for it.
> >
> > How can we enforce user-space to report the appl_ptr update?  The way
> > is relatively simple.  Just by disabling the PCM control mmap, the
> > user-space is supposed to fall back to the mode using SYNC_PTR ioctl,
> > and the kernel gets control over that.  This fallback mode is used in
> > all non-x86 platforms as default, and also in the 32bit compatible
> > model on all platforms including x86.  It's been implemented already
> > over a decade, so we can say it's fairly safe and stably working.
> >
> > With the help of the knowledge above, this patch introduces a new PCM
> > info flag SNDRV_PCM_INFO_SYNC_APPLPTR for achieving the appl_ptr sync
> > from user-space.  When a driver sets this flag at open, the PCM status
> > / control mmap is disabled, which effectively switches to SYNC_PTR
> > mode in user-space side.
> >
> > In this version, both PCM status and control mmaps are disabled
> > although only the latter, control mmap, is the target.  It's because
> > the current alsa-lib implementation supposes that both status and
> > control mmaps are always coupled, thus it handles a fatal error when
> > only one of them fails.
> >
> > Of course, the disablement of the status/control mmaps may bring a
> > slight performance overhead.  Thus, as of now, this should be used
> > only for the dedicated devices that deserves.
> >
> > Note that the disablement of mmap is a sort of workaround.  In the
> > later patch, we'll introduce the way to identify the protocol version
> > alsa-lib supports, and keep mmap working while the sync_ptr is
> > performed together.
> >
> > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > ---
> >   include/uapi/sound/asound.h |  1 +
> >   sound/core/pcm_native.c     | 23 +++++++++++++++++++++--
> >   2 files changed, 22 insertions(+), 2 deletions(-)
> 
> Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
> 
> I note that this patch changed 'asound.h'. We have a plan to bump up
> protocol version in future patches.

Right, it's still compatible with the existing ABI, so it should work
without the protocol version bump.  We can increase it now, but we'll
do another update soon, so let's wait for a while.

I merged this patch now.


thanks,

Takashi