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

[Takashi Iwai <tiwai@suse.de>]

On Mon, 19 Jun 2017 14:33:50 +0200,
Takashi Sakamoto wrote:
> 
> On 2017年06月19日 02:08, 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?
> 
> Applications still works well because they receive proper set of
> hw_params. They works as programmed, thus for the new devices/drivers
> they work without mmap operation.

This solution is obviously worse from most of perspectives (the
performance, the possible regressions).


> > 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?
> 
> I will not have this direction, past and future, because this issue
> demands userland stuffs to perform as the new drivers/devices expects,
> thus userland stuffs _should_ be changed.

Have you ever heard of a distribution named "Debian"?  Wait for
another 10 years until the fix in a newer alsa-lib version will be
distributed as stable :)


thanks,

Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel