[alsa-devel] Polling issues with the PCM multi plugin
Hi all,
On the jack-devel list, we've been having a discussion about the ALSA PCM multi plugin:
http://thread.gmane.org/gmane.comp.audio.jackit/26571/focus=26571
I've been having some issues with setting up my 2 Echo Layla 3Gs as a PCM multi. In particular, I've found that there are times when polling the file descriptors of the multi when poll() returns, but there isn't actually a period of data available for capture/playback, even though the poll descriptors indicate that the data should be available. After some debugging and learning about the PCM multi driver:
1.) The PCM multi driver only returns poll descriptors for one of the devices that makes up the multi 2.) When this happens, the device that's actually being polled *does* have data available 3.) When this happens, the device that's not being polled does not yet have a period's worth of data available
After making sure that I had word clock enabled and that my word clock cable was working properly, I started delving into the problem some more. From what I can gather, the PCM multi device uses the function `snd_pcm_link()` to sync its devices, and, for start, stop, drain, pause, suspend, resume, reset, and prepare operations, this appears to work fine; however, I can't find any evidence that a PCM device checks to make sure that all of its linked slave devices have their poll descriptors ready with events before indicating that events are available.
Questions:
1.) Should `snd_pcm_link` make I/O availability indication dependent on I/O availability of its linked slave devices? 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.
Thanks,
At Wed, 12 Dec 2012 21:57:56 -0800, Devin Anderson wrote:
Hi all,
On the jack-devel list, we've been having a discussion about the ALSA PCM multi plugin:
http://thread.gmane.org/gmane.comp.audio.jackit/26571/focus=26571I've been having some issues with setting up my 2 Echo Layla 3Gs as a PCM multi. In particular, I've found that there are times when polling the file descriptors of the multi when poll() returns, but there isn't actually a period of data available for capture/playback, even though the poll descriptors indicate that the data should be available. After some debugging and learning about the PCM multi driver:
1.) The PCM multi driver only returns poll descriptors for one of the devices that makes up the multi 2.) When this happens, the device that's actually being polled *does* have data available 3.) When this happens, the device that's not being polled does not yet have a period's worth of data available
After making sure that I had word clock enabled and that my word clock cable was working properly, I started delving into the problem some more. From what I can gather, the PCM multi device uses the function `snd_pcm_link()` to sync its devices, and, for start, stop, drain, pause, suspend, resume, reset, and prepare operations, this appears to work fine; however, I can't find any evidence that a PCM device checks to make sure that all of its linked slave devices have their poll descriptors ready with events before indicating that events are available.
Questions:
1.) Should `snd_pcm_link` make I/O availability indication dependent on I/O availability of its linked slave devices?
The PCM stream link has nothing to do with the poll descriptors. It's basically only for performing the synchronized trigger.
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.
Maybe as a compromised solution, we'd need to introduce a config option to multi plugin for allowing multiple fds.
Takashi
On Wed, Dec 12, 2012 at 10:34 PM, Takashi Iwai tiwai@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 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.
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. :)
At Wed, 12 Dec 2012 23:04:16 -0800, Devin Anderson wrote:
On Wed, Dec 12, 2012 at 10:34 PM, Takashi Iwai tiwai@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
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,
On Thu, Dec 13, 2012 at 7:43 PM, Devin Anderson surfacepatterns@gmail.com wrote:
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?
Scratch that. I just read pcm.c in the tests folder in alsa-lib, which calls `snd_pcm_poll_descriptors()` only once, and then polls thereafter. Oh well.
participants (2)
-
Devin Anderson -
Takashi Iwai