[alsa-devel] Polling issues with the PCM multi plugin
tiwai at suse.de
Thu Dec 13 08:25:18 CET 2012
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
> 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.
More information about the Alsa-devel