>>> do snd_pcm_period_elapsed really handle the case when more than one period >>> are elasped ? >>> >>> For au88x0 , each substream have four sets of hardware registers , it seem >>> that the driver can recover lost interrupt with no underrun when using very >>> small period size >>> >>> >>> http://www.alsa-project.org/~tiwai/writing-an-alsa-driver/ch05s07.html#pcm-interface-interrupt-handler-boundary <http://www.alsa-project.org/%7Etiwai/writing-an-alsa-driver/ch05s07.html#pcm-interface-interrupt-handler-boundary> >>> >>> On calling snd_pcm_period_elapsed() >>> >>> In both cases, even if more than one period are elapsed, you don't have to >>> call snd_pcm_period_elapsed() many times. Call only once. And the pcm layer >>> will check the current hardware pointer and update to the latest status. >> Yes, the new code handles more alapsed periods, too. The in_interrupt >> check is mainly for situations when period count == 1 and it compares >> expected next hw_ptr for interrupt with hw_ptr computed from the hw_base >> and actual position in the ring buffer. >> Jaroslav The value "delta" returned by vortex_adbdma_bufshift() seem to be the number of sub-buffer(periods) elapsed ( the value can be 0 , 1 , 2 or 3 ) when aplay using very small period_size (e.g. 16 ) , the driver write message in system log when delta > 1 (i.e. more than 1 period have been elapsed ) but the sound is still ok since there are two more periods in the sub-buffer But I cannot see any code in snd_pcm_period_elasped() add two period size to hw_ptr _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
