>> 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. > >In this case you'd have both revents set (with a lowlevel driver that >take care of that). >However I don't think this worth the effort: it's a small window.
it seems rather bizarre that for h/w which is capable of full duplex that we (may) have to go into the kernel twice to find out that both streams are ready to use. even more bizarre on h/w that is guaranteed to run in sync (eg. the hammerfalls). seems like we want a new h/w info flag SNDRV_PCM_SINGLE_HW_PTR or something similar, so that this can be avoided on h/w where it really isn't needed. it seems like an inevitable outcome of the division between capture and playback streams though. it think that its absolutely guaranteed that as long as the capture and playback streams can call wakeup() independently, then SMP systems will suffer from this issue from time to time (it takes < 12usec to start the now-runnable SCHED_FIFO thread - if the second pass through snd_pcm_update_hw_ptr_interrupt() takes long than that, the "race" is going to happen). and on h/w like the trident, where its not even the same interrupt handler, its even more likely to occur, even on UP systems. for now, i'm adding the full duplex poll to the JACK driver code, but its with some reluctance - this is quite ugly. --p _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
