At Mon, 2 Feb 2009 15:49:13 +0100, Lennart Poettering wrote:
On Mon, 02.02.09 08:02, Takashi Iwai (tiwai@suse.de) wrote:
If we look into the pcm example how snd_pcm_poll_descriptors_revents() is used then we can see that the revents parameter apparently is supposed to be a single integer. (which makes a lot of sense to me)
http://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2pcm_8c-example.html#a3...
However, snd_pcm_wait_nocheck() calls the same function and assumes it is a complete array!
http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=src/pcm/pcm.c;h=74d1d1a...
So what's it now? It makes more sense to me if it would be a single fd.
No, it's a bug in test/pcm.c. As documented, the API converts (fixes) each poll_fd in the given array.
But does that really make sense? I mean snd_pcm_poll_descriptors_revents() is supposed to be called by applications that integrate ALSA into some kind of event loop. What are they supposed to do with those multiple entries -- except simply ORing them together and treating them as one? The application has no information what those seperate fds mean, so why export that information to the app?
Originally the multiple pfds were introduced to handle multi plugin, which bundles multiple instances. So, the original version of it was pretty straightforward -- just simply calls poll to each and update each pfd necessarily.
After some time, multi plugin itself was changed to expose only a single pfd, so there is no meaning for that. That's why it never got a realistic problem. Meanwhile, hw pcm introduced the multiple pfds again (for cases with timer), and this could be a problem again right now.
It's not about the question whether it makes sense. It *was* designed so originally although it's fairly useless. Due to the uselessness, one side got fixed, but another side remained.
Takashi