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