[alsa-devel] Polling issues with the PCM multi plugin
surfacepatterns at gmail.com
Thu Dec 13 08:04:16 CET 2012
On Wed, Dec 12, 2012 at 10:34 PM, Takashi Iwai <tiwai at suse.de> wrote:
>> 2.) If not, how should this operation be handled? I'm sure it *can*
>> be handled in userspace by bypassing the multi and polling the file
>> descriptors of all sound cards directly, but duplicating this code for
>> each application that wants to poll multiple sound cards seems wrong.
> Actually there were multiple poll descriptors for multi plugin in the
> early version of alsa-lib. But this was changed to a single fd by
> some reason I don't remember. I thought there were too many broken
> apps doing wrong for multiple fds.
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.
As an example, let's consider what the multi plugin should do when
`snd_pcm_poll_descriptors_revents()` is called. It basically has two
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.
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.
Please correct me if I'm wrong. I really *want* to be wrong about this. :)
surfacepatterns (at) gmail (dot) com
blog - http://surfacepatterns.blogspot.com/
psinsights - http://psinsights.googlecode.com/
synthclone - http://synthclone.googlecode.com/
More information about the Alsa-devel