On Tue, 2007-10-09 at 11:48 +0200, Takashi Iwai wrote: > You need to unlock sis->hw_lock before calling > snd_pcm_period_elapsed(). It may call snd_pcm_stop() at XRUN, and > this invokes the trigger callback, which locks hw_lock again. > Simply re-acquire hw_lock after calling snd_pcm_period_elapsed(). If I'm guaranteed that I'll never have my prepare() method called concurrently for the same substream, I think I can do away with the hw_lock completely -- though I need to think through scenarios about closing the stream and a late interrupt... It looks like my prepare() gets called by snd_pcm_action_nonatomic() in sound/core/pcm_native.c, and that takes a read lock on the link semaphore, so the group won't be changed, but I don't see anything that would prevent prepare() being called twice on the same substream concurrently. So, I'll probably need to keep some locking to avoid an issue there, unless I'm missing a lock upstream. I'll have a look at removing locks from the interrupt handler completely, though. Thanks, Dave _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
