alsa: Avoid busy loop with dmix.
authorAndre Noll <maan@systemlinux.org>
Sat, 8 Oct 2011 17:16:14 +0000 (19:16 +0200)
committerAndre Noll <maan@systemlinux.org>
Tue, 18 Oct 2011 17:29:33 +0000 (19:29 +0200)
When using alsa's direct mixing plugin, the alsa poll fd might be ready
for IO even though nothing can be written to the alsa handle. This
leads to a busy loop in para_audiod and para_write and makes these
applications eat up considerable amounts of CPU time during playback.

This patch fixes the problem by reading from the alsa fd after a
failed write. It also adjusts the test for when to return early from
alsa_post_select(). The old code was not wrong, however, since we
should never reach the test if poll_fd is negative.

alsa_write.c

index 047e88f..b89c8c3 100644 (file)
@@ -248,12 +248,23 @@ again:
                wn->min_iqs = pad->bytes_per_frame;
                goto again;
        }
-       if (pad->poll_fd >= 0 && !FD_ISSET(pad->poll_fd, &s->rfds))
+       if (pad->poll_fd < 0 || !FD_ISSET(pad->poll_fd, &s->rfds))
                return;
        frames = bytes / pad->bytes_per_frame;
        frames = snd_pcm_writei(pad->handle, data, frames);
-       if (frames == 0 || frames == -EAGAIN)
+       if (frames == 0 || frames == -EAGAIN) {
+               /*
+                * The alsa poll fd was ready for IO but we failed to write to
+                * the alsa handle. This means another event is pending. We
+                * don't care about that but we have to dispatch the event in
+                * order to avoid a busy loop. So we simply read from the poll
+                * fd.
+                */
+               char buf[100];
+               if (read(pad->poll_fd, buf, 100))
+                       do_nothing;
                return;
+       }
        if (frames > 0) {
                btr_consume(btrn, frames * pad->bytes_per_frame);
                goto again;