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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
