It looks like that the capture direction receives an interrupt before the
>capture pointer has reached the period size boundary. You can increase the
>insterrupt delay, something like this:

i'll check on that, but i don't think thats what happened above. this
should make it clearer (i processed the log this time):

----------------------------------------------------------------------

   elapsed msecs  interval  cycle   event
                   usecs   counter
  -----------------------------------------------------------------------

    2.644553     1171.313  5043063  trident interrupt chn = 0x40000000 

capture interrupt discarded as spurious (but history is not shown)

    2.671316       26.762  5055106  trident interrupt chn = 0x80000000 
    2.686758       15.442  5062055  wakeup stream playback with 66 (since capture 
wake: 644915) 

only playback woken, capture is still sleeping

    2.704093       17.336  5069856  playback poll 2601: avail = 66 
    2.712380        8.287  5073585  capture poll 2679: avail = 2 
    2.841204      128.824  5131556  capture poll 2680: avail = 2 

    4.150211     1309.007  5720609  trident interrupt chn = 0x80000000 

next period, interrupt received, for playback only

    4.166867       16.656  5728104  wakeup stream playback with 130 (since capture 
wake: 1310964) 
    4.186267       19.400  5736834  trident interrupt chn = 0x40000000 

capture interrupt received, but discarded as spurious (too close to
last interrupt (16+19 = 35usecs or 1.54 samples)). capture stream not
woken.

    5.568176     1381.909  6358693  trident interrupt chn = 0x80000000 

next period, playback interrupt received

    5.584111       15.936  6365864  wakeup stream playback with 193 (since capture 
wake: 1948724) 

wake up playback

    5.603336       19.224  6374515  trident interrupt chn = 0x40000000 

capture interrupt received (matches previous playback interrupt?)

    5.621320       17.984  6382608  wakeup stream capture with 66 (since capture wake: 
1965468) 

this time, its 17+19 = 36 usec later ... hmm, this is still on 1.55
samples, so how come it succeeds at waking up the capture stream
instead of being discarded?
----------------------------------------------------------------------

i'll have to add some more tracing code to make sure i see all the
discards. right now, i'm infering them from the code logic, but
apparently something else can happen.

--p



_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Reply via email to