At Tue, 21 Oct 2008 11:08:17 +0400, Stas Sergeev wrote:
Hi.
Takashi Iwai wrote:
The PCM status is changed immediately after calling trigger(async) callback XRUN or SETUP. That is, you can start the stream again soon after snd_pcm_stop(). In the case of async operation, the hardware may be likely still running, but the PCM core doesn't know about it and allows you to restart the stream. So it's racy, at least from the PCM core viewpoint.
OK but how does _my patch_ affects this?
No, your patch does essentially NOTHING by itself. However...
Before, the trigger() callback was called both synchronously and asynchronously. My patch only provides the callback to make it possible to separate the sync and async parts. It doesn't do anything more. It doesn't change anything at all. So how could exactly that patch introduce the race you mentioned? There was already an async invocation of trigger() callback. I wanted to add just a callback under different name for that. What could my patch possibly change? How does it _introduce_ the race?
Because the async trigger itself can be racy easily, there is no merit to add a common callback until we have a proper handling of delayed triggers in the PCM core side.
Takashi