On Mon, 11 Jan 2010, pl bossart wrote: >>> I couldn't figure out who generates this null event, and even better >>> it does not show in the report printed by my test app. I am somewhat >>> lost here as to how snd_pcm_playback_poll works. >> >> Note that do_poll() in linux/fs/select.c first checks all given fds >> if there's an event. So probably the userspace just called poll() for a >> reason in different timing than sound one (processing event from another fd >> or so). I believe it's normal behaviour. > > This was tested with alsa-lib/test/pcm.c; there's only one call to > poll() with a -1 timeout value. What I fail to understand is why I see > this null event in pcm_native.c, and nothing reported in userspace by > the wait_for_poll() loop in alsa-lib/test/pcm.c Userspace: poll() syscall Kernel: do_poll() 1) call f_ops->poll callback to ensure that poll condition is not set (it's usually your null event) 2) go to sleep and wait for wake_up 3) call f_ops->poll callback again to check which fd woke up 4) leave to user space The f_ops->poll callback is called twice in a normal situation. Jaroslav ----- Jaroslav Kysela <perex@xxxxxxxx> Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
