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@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
