On Wed, Dec 12, 2012 at 11:25 PM, Takashi Iwai tiwai@suse.de wrote:
At Wed, 12 Dec 2012 23:04:16 -0800, Devin Anderson wrote:
Are the apps really doing the wrong thing? It seems like `snd_pcm_poll_descriptors()` and `snd_pcm_poll_descriptor_revents()` are meant to operate on a single group of file descriptors, without interpreting what the availability of events on each particular file descriptor might mean. This leads to some problems.
Yes, grouping multiple descriptors gives ambiguity. It must be a part of the problems.
As an example, let's consider what the multi plugin should do when `snd_pcm_poll_descriptors_revents()` is called. It basically has two options:
1.) Return I/O events when one or more file descriptors have I/O events
This is obviously problematic, as there may only be partial data available. This is also how the multi plugin works today.
Right, and this behavior hasn't been changed, AFAIK.
2.) Return I/O events when all file descriptors have I/O events.
In this scenario, `poll()` will return when events are available on at least one poll descriptor, leading to busy waiting via `poll()` until I/O events are available on all file descriptors.
Never implemented in such a way, so far, because this can very easily lead to XRUN.
So, how can this problem be solved?
I have an idea that I'd like to explore, but it's dependent on the idea that `snd_pcm_poll_descriptors()` needs to be called before every `poll()` call, and I'm not sure if that's a reasonable expectation. Is `snd_pcm_poll_descriptors()` a function you can call once, and then depend on working through multiple `poll()` calls, or is it required that `snd_pcm_poll_descriptors()` be called for every call to refresh the descriptors and the events they should be polled for?
Thanks,