[alsa-devel] [RFC][PATCH] ALSA: pcm: introduce ACK_APPLPTR flag and bump up interface version to v2.0.14

[Takashi Iwai]

On Sun, 18 Jun 2017 18:49:18 +0200,
Takashi Sakamoto wrote:
> 
> Hi,
> 
> This patchset includes commits for both kernel/user land for an issue
> addressed in this message thread[1].
> 
> In a development period for v4.13, it's clear that there's a type of
> devices which demand userspace applications to change their behaviour.
> These devices can take care of application-side pointer on PCM buffer
> for their data transmission. As a result, these devices achieve some
> advantages. For these devices, drivers need to get feedback about
> current position of the pointer from applications when they
> queue/dequeue PCM frames on the buffer.
> 
> ALSA PCM core partly assist the above design. The core can call a
> handler in driver side when applications operate PCM frames by
> ioctl(2) with SNDRV_PCM_IOCTL_[READ|WRITE][N|I] command. However,
> when operating for mapped PCM buffer, it can't assist applications
> for the above design. In this scenario, applications should call
> ioctl(2) with SNDRV_PCM_IOCTL_SYNC_PTR after handle any PCM frames on
> the buffer.
> 
> This patchset bumps up interface version with new info flag to
> notify the above change to user land developers. This patchset is
> written with below ideas:
> 
> 1. Stuffs in user land can tell their assists for the above design
>    to kernel land by using hw_param flag. When they don't assist,
>    they see on hw_params data that mmap operation is not supported.
> 2. Drivers can acknowledge the above flag. When registering
>    appropriate PCM rules in advance, they can calculate values for
>    each parameters in both cases that stuffs in user land can/cannot
>    assist it. This is useful for packet-oriented drivers to judge
>    utilizing any interrupt context for packetization.
> 3. This is device-specific issue, independently of platform
>    architecture. On x86/ppc/alpha platforms, status/control data of
>    PCM substream is still available in process' VMA of application via
>    page frame mapping.
> 
> [1] http://mailman.alsa-project.org/pipermail/alsa-devel/2017-June/121438.html
> 
> For kernel land:
> Takashi Sakamoto (1):
>   ALSA: pcm: introduce ACK_APPLPTR flag and bump up interface version to
>     2.0.14
> 
>  include/uapi/sound/asound.h | 11 ++++++++++-
>  sound/core/pcm_native.c     | 25 +++++++++++++++++++++++++
>  2 files changed, 35 insertions(+), 1 deletion(-)
> 
> For user land:
> Takashi Sakamoto (2):
>   ALSA: pcm: introduce ACK_APPLPTR flag and bump up interface version to
>     2.0.14
>   pcm: add support for interface version 2.0.14
> 
>  include/sound/asound.h | 11 ++++++++++-
>  src/pcm/pcm_hw.c       | 43 +++++++++++++++++++++++++++++++++++++------
>  2 files changed, 47 insertions(+), 7 deletions(-)

Well, these mandate both kernel and user-side changes, so if you run
the old applications with old alsa-lib, it can't work, right?

A similar patchset is already in my local queue (my version called it
differently, SNDRV_PCM_INFO_SYNC_APPLPTR :), but it wasn't submitted
yet because we wanted to fix the issue without affecting alsa-lib at
first.  Do you have the patch for that?


thanks,

Takashi