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