On Jun 19 2017 02:17, Takashi Iwai wrote:
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.
Just for drivers/hardwares with the new flag. I won't disable page frame
mapping of control/status data indiscriminately for drivers with .ack
callback.
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.
Old stuffs were not programmed to assist the new devices/drivers. It's
quite natural to get a constrain to its working mode for several
drivers/devices.
I focus on describing hardware/driver capabilities in interface for user
land reasonably, instead of introducing them ex post facto.
...Well, I've already done for my proposal to this issue. Nothing left.
I think you can understand what I insists for this issue and my concerns
about your patch.
If you updates change log in the patch and post it, I'm willing to
review it. I don't oppose it so hard (I understand the intention
correctly), however it's important to pay enough attention to interfaces
for applications. If the new stuffs bring changes to interface and
applications get affects, we, developers for kernel land, should record
and explain about it.
Regards
Takashi Sakamoto
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
