• Takashi Iwai's avatar
    ALSA: pcm: Add the explicit appl_ptr sync support · 42f94597
    Takashi Iwai authored
    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.
    Reviewed-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
    Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
    42f94597
asound.h 45.3 KB