Re: More snd_pcm_ioplug_avail_update() questions

[Takashi Iwai <tiwai@suse.de>]

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