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

[Takashi Sakamoto]

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.

> 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.

# When I investigated name of the flag, I dropped
# 'SNDRV_PCM_INFO_SYNC_APPLPTR' at first, because hardware doesn't
# need to synchronize to applptr always. It's enough for hardwares to
# get it when requires. Drivers and applications assist it.


Regards

Takashi Sakamoto