[alsa-devel] Polling issues with the PCM multi plugin

[Takashi Iwai]

At Wed, 12 Dec 2012 23:04:16 -0800,
Devin Anderson wrote:
> 
> 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.

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.


Takashi