[alsa-devel] [PATCH 1/2] ALSA: firewire: process packets in 'struct snd_pcm_ops.ack' callback

[Takashi Sakamoto]

Hi,

On Jun 15 2017 17:48, Takashi Iwai wrote:
 > Well, I still don't understand (anyone else can?) what you mean as "a
 > change of programming model" at all.

Here, I refer to my former message.

On Jun 13 2017 07:49, Takashi Sakamoto wrote:
 > Let me evaluate this patch in a point of overhead at kernel/userspace
 > interaction.
 >
 > When considering about shape of ALSA PCM applications, I can show it by
 > below simple pseudo code:
 >
 > ```
 > while:
 >    poll(2)
 >    calculate how many PCM frames are available.
 >    memcpy(2)
 > ```
 >
 > To satisfy requirements of some drivers, we need to find a way to take
 > userspace applications to commit the number of handled PCM frames to
 > kernel space after the memcpy(2). For this purpose, in ALSA PCM
 > interface, SNDRV_PCM_IOCTL_SYNC_PTR is available.
 >
 > ```
 > while:
 >    poll(2)
 >    calculate how many PCM frames are available.
 >    memcpy(2)
 >    ioctl(2) with SNDRV_PCM_IOCTL_SYNC_PTR
 > ```

Some devices/drivers request applications to perform this, due to their
design of hardware for data transmission.

 > It's becoming again like a typical situation you falling often into
 > while discussing with others; your new term is too ambiguous and
 > unique to parse without a clarification.  PLEASE, clarify your idea
 > in a more understandable way, at best with a (pseudo-) code snippet.

The above.

 > And, I think you miss a few points, thus the argument was twisted.
 >
 > - The primary goal is to achieve the notification of appl_ptr change
 >    to kernel.

It's for the purpose to support devices which have the new design for
data transmission. This is the reason that I agree with upgrading
version of PCM interface. I suggest adding new info flags for the
specific purpose.

Disabling mmap for status/control data of PCM substream is just to
support architectures to which ALSA PCM core judge non cache coherency.
It's not good to utilize it as a solution of this issue because of
abuse of interfaces.

 > - The kernel needs to work with the existing user-space.
 >    It's a MUST.

I described in a previous message.

On Jun 14 2017 23:34, Takashi Sakamoto wrote:
 > When working with old userspace stuffs, drivers run with old mode
 > (namely, run for current interface). The difference of interface
 > version is absorbed in alsa-lib as much as possible, then application
 > runs without large change

 > - appl_ptr or whatever a status *is* maintained in kernel -- or better
 >    to say, it's kept in both kernel and user-space.  (Otherwise why it
 >    becomes a problem now?)

This is not achieved in current implementation of ALSA PCM core yet.
Even if hardware generates any event to get current application-side
position on PCM buffer, it can't be achieved. There's no way for
hardwares. Therefore, it's unavoided to request userspace to have care
of the above pseudo code, when supporting devices with the new design.

 > So, if you have a better idea for achieving the goal without changing
 > the current ABI, please tell us.  It'd be really appreciated!
 >
 > For the future development with the ABI extension, we may do implement
 > in a different level, yes.  Basically we can change everything.  But
 > this is not the thing we need to fix right now.
 >
 > I'm open for any changes with the ABI extension.  It's certainly
 > exciting.  But, don't mix up this with the solution for the current
 > implementation.

Your idea to extend current ABI includes some jumps from current
position of discussion. At least, the reason of it is somehow based on
your idea to disable mmap for control/status data of PCM substream for
some devices/drivers. As already stated, I'm against it with several
reasons. On cache coherent architecture, there's no matter to consider
about it. Thus they're not matters to me at present.


Regards

Takashi Sakamoto