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