here are two consecutive return-from-poll situations:
--------------
poll events = 0x4, checking capture avail
capture: hwptr = 193 apptr = 128 <= OK, hwptr += 64, apptr += 64
checking playback avail
playback: hwptr = 193 apptr = 256 <= OK, hwptr += 63, appptr += 64
hw avail: c:65 p:65
this time = 64
capture: hwptr = 193 apptr = 128
playback: hwptr = 193 apptr = 256
contiguous = 64
capture: hwptr = 193 apptr = 128
playback: hwptr = 193 apptr = 256
--------------
poll events = 0x4, checking capture avail
capture: hwptr = 193 apptr = 192 <== UH-OH. hwptr has not advanced
checking playback avail
playback: hwptr = 258 apptr = 320 <== playback hwptr += 63
hw avail: c:1 p:66
this time = 0
----------------------------------------------------------------------
i don't understand how we could ever find a situation where the
playback ptr has moved by 64 frames and the capture pointer has not.
oh wait. oh yes i do. we run with SCHED_FIFO. the thread handling this
stuff gets woken up and runs on the other processor before the
interrupt handler has finished running. the handler finds the playback
stream, and calls snd_pcm_period_elapsed for that playback stream,
which wakes us up, then continues on to execute the same code for the
capture stream. we return from poll before the information about the
capture stream has been updated.
yikes. ugly.
ok, i'll go get my daughter from school and think about this on
the way there and back. maybe full duplex poll is required, but it
seems awfully heavyweight for full duplex h/w where the playback and
capture streams should be running synchronously.
--p
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
