On Thu, 26 Jul 2018 17:02:33 +0200, Rob Duncan wrote:
At 07:37 on Thu, Jul 26 2018, Takashi wrote:
OK, I seem to have misunderstood about what you meant as committed in the context. Yes, if the available is partial, it might be not committed. But I don't understand the next part.
How will it be discarded at the next snd_pcm_ioplug_avail_update()? The data remains on the buffer, and applptr isn't changed.
Yes, that's the problem. Because when snd_pcm_ioplug_avail_update() is subsequently called it uses snd_pcm_mmap_begin() to get the offset into the mmap for the destination of the capture transfer operation. This is essentially appl_ptr, which means that the data that has not yet been commited will be overwritten by the transfer.
OK, point taken. Yeah, if the ioplug driver expects that the transfer happens only once, it's a problem.
I guess that the offset could somehow be adjusted to point to after the uncommitted data but I don't see a straightforward way to do that. A scheme along these lines would also have to adjust the size parameter accordingly, of course. This would sometimes mean that we cannot transfer all the available data from the IO plugin. Would that cause any issues?
Maybe we can track the own applptr (e.g. transfer_ptr or such) and calculate the transfer size from it instead of snd_pcm_mmap_begin(); i.e. write some open codes of alternative snd_pcm_mmap_begin() there.
Then transfer_ptr is updated again in snd_pcm_ioplug_mmap_commit() as well when applptr is updated.
Of course, there is a smarter way, I'd happily take another approach.
thanks,
Takashi