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

[Takashi Iwai <tiwai@suse.de>]

On Sun, 18 Jun 2017 19:08:05 +0200,
Takashi Iwai wrote:
> 
> 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?

I see now that you achieved it by dropping the whole mmap.

This is a very big concern from the performance POV.  It merely kills
the whole merit of adding the appl_ptr notification (e.g. PA switches
to a completely different mode), so this is likely no-go, sorry.


thanks,

Takashi