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