bugme-daemon@xxxxxxxxxxxxxxxxxxx wrote: > ------- Comment #17 from tiwai@xxxxxxx 2008-05-18 10:22 ------- > Anyway, what I meant is that the part touching I/O ports could be a faster path > than softirq. And the hrtimer code can use a bit simpler locks. The hrtimer > callback needs just one thing about DMA buffer - the buffer is allocated and > the address doesn't change during the callback. So, we'd need the lock for the > hr callback and for the PCM prepare, hwparams and free callbacks, i.e. to > assure that the hrtimer callback is finished when these PCM callbacks may > change the DMA buffer. Thus this lock doesn't have to be PCM substream lock. I wonder if it would be better to introduce such a lock in an alsa core rather than in a driver. The same way as snd_pcm_stream_lock(). > The current lock mess may come from the PCM trigger (STOP) called from > snd_pcm_period_elapsed(). So, putting snd_pcm_period_elapsed() out of hrtimer > lock is anyway necessary. A tasklet for snd_pcm_period_elapsed() is needed for > this reason, too. Wouldn't it be better to just make snd_pcm_period_elapsed() to not take the stream lock? There is a requirement right now to drop the stream lock before calling this. I still beleive this is the root of all the headache. If you need to drop it, then you either accept the race or need a second lock, and the troubles ensue. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
