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-i... 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