On Fri, 23 Mar 2018 09:01:35 +0100,
Takashi Iwai wrote:
>
> On Fri, 23 Mar 2018 08:43:10 +0100,
> Wischer, Timo (ADITG/ESB) wrote:
> >
> > > No, again, in non-blocking mode, the drain callback will get never
> > > called. It's the responsibility of application to sync with poll()
> > > instead.
> >
> > Sorry but I do not get it anyway.
> >
> > The user application which is playing some audio has to do the following to drain in nonblocking mode, right?
> > snd_pcm_poll_descriptors(pfds)
> > while (snd_pcm_drain() == -EAGAIN) {
> > poll(pfds)
> > }
> >
> >
> > But in nonblocking mode the drain callback of the IO plugin will never be called with your solution.
> > Therefore in case of the pulse IO plugin which function should call pa_stream_drain()?
> > The user application will not do it directly and poll can also not call it.
>
> OK, now I understand your concern. Yes it's another missing piece,
> snd_pcm_ioplug_hw_ptr_update() needs to check the current state, and
> it drops to SETUP state instead of XRUN when it was DRAINING.
> Then application can simply do poll() and status update until it goes
> out of DRAINING state.
>
> But still it's outside the plugin, drain callback isn't called there.
.... and now thinking of this again, the whole story can be folded
back:
- The standard drain behavior can be implemented without plugin's own
code; it's just a poll and status check.
- For any special case (or better implementation than poll()), we may
leave the whole draining callback action to each plugin; that's the
case of PA.
Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
