Re: [PATCH - IOPLUG DRAIN 0/2]

From: Takashi Iwai <tiwai@suse.de>
To: Takashi Iwai <tiwai@suse.de>
Cc: "Wischer, Timo (ADITG/ESB)" <twischer@de.adit-jv.com>,
	"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>
Subject: Re: [PATCH - IOPLUG DRAIN 0/2]
Date: Fri, 23 Mar 2018 09:08:43 +0100	[thread overview]
Message-ID: <s5htvt79ptg.wl-tiwai@suse.de> (raw)
In-Reply-To: <s5hwoy39q5c.wl-tiwai@suse.de>

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