I've been experiencing an occational error, about twice a day, since the upgrade of alsa-lib. Both on builtin HDA sound card and my old trusty SB-Live. I am not using pulseaudio.
Under some circumstances, that I have yet to determine, any application trying to play sound will get an EBADFD (File descriptor in bad state) when accessing the alsa-device. The only solution I've figured out is to rmmod and modprobe the driver (snd-hda-intel or snd-emu10k1), or downgrade to previous alsa-lib.
When the error occurs, if I downgrade to 1.1.0, everything is fine, and upgrade to 1.1.1, EBADFD again, until rmmod+modprobe. So the problem seems to actually be with alsa-lib 1.1.1.
I have diffed the source trees of 1.1.0 and 1.1.1, but can't see any obvious culprit. Next chance I get, I'll try do a more thorough investigation to figure out if it is an alsa bug, a hardware failure or whatever the cause might be.
In the meantime, if anybody else has stumbled upon the problem, please share.

EBADFD seems to be the favorite error code returned by the kernel to any command when the sound system is not in the expected state. It appears in dozens of places. It may be that your alsa-lib version is tested against a different kernel.

http://lxr.free-electrons.com/ident?i=EBADFD

1 members found this post helpful.

After recompiling the kernel the problem went away for a couple of days, but started reappearing again. So I reported it to alsa-lib upstream (see http://mailman.alsa-project.org/pipe...il/106739.html). It was caused by a commit about three weeks before 1.1.1 was released, where one race condition was eliminated, but another one surfaced, which has now been fixed in fdba9e1bad8f769a6137e565471f0227f23a3132.