after hacking both the kernel driver and alsa-lib, this is the view
from user-space. each block between "----" is single return from
poll(2). i added code to print the values of the hw_ptr and appl_ptr
from within alsa-lib.
-----------------------
hwptr = 65 apptr = 0
hwptr = 128 apptr = 64
hw avail: c:64 p:66
this time = 64
hwptr = 128 apptr = 64
contiguous = 64
-----------------------
hwptr = 128 apptr = 64
hwptr = 193 apptr = 128
hw avail: c:65 p:65
this time = 64
hwptr = 193 apptr = 128
contiguous = 64
-----------------------
hwptr = 193 apptr = 128
hwptr = 193 apptr = 192 <=== THIS
hw avail: c:1 p:66
this time = 0
the line marked THIS seems impossible to me. we've returned from
poll(2), but only one hwptr has changed since the last time. i just
don't understand how this can happen. unless its an xrun, but that
seems unlikely given that the code run here takes about 2usec
to execute, is mlocked and SCHED_FIFO'ed. any suggestions of how to
study this some more?
the appl_ptr is being updated correctly by snd_pcm_mmap_commit() (it
moves forward 64 frames each time).
i have a kernel space trace too, but it seems too hard to sync up the
output from there with the userspace dump.
needless to say, i don't see this on the hammerfall (not suprising
since there is only one hw_ptr for both playback and capture).
--p
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
