Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
File descriptor in bad state
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Multimedia
View previous topic :: View next topic  
Author Message
jiaxi
n00b
n00b


Joined: 25 Sep 2012
Posts: 30

PostPosted: Thu Dec 05, 2013 8:05 am    Post subject: File descriptor in bad state Reply with quote

I get the log of fd in bad state when using aplay to play the wav file.

ALSA lib pcm_dmix.c:1068:(snd_pcm_dmix_open) unable to open slave
File descriptor in bad state

And i check the fd of /dev/pcmC0D0p. I can get the result:
# ls -l /proc/1384/fd
lr-x------ 1 root root 64 Dec 5 22:20 19 -> /dev/timer
lrwx------ 1 root root 64 Dec 5 22:20 2 -> /dev/console
lrwx------ 1 root root 64 Dec 5 22:20 20 -> socket:[4365]
lrwx------ 1 root root 64 Dec 5 22:20 21 -> socket:[4371]
lrwx------ 1 root root 64 Dec 5 22:20 23 -> /dev/pcmC0D0p (deleted)

when i kill the pid of 1384,the aplay can work well.

Why?
Back to top
View user's profile Send private message
causality
Apprentice
Apprentice


Joined: 03 Jun 2006
Posts: 171

PostPosted: Mon May 02, 2016 5:39 pm    Post subject: Reply with quote

The "File descriptor in bad state" error only happens to me after a reboot.

In my case I believe the problem was caused by Timidity crashing on system start-up. This is the relevant line from the output of dmesg:

Code:
[   29.220134] timidity[2335]: segfault at 0 ip 00007f650001d61d sp 00007ffcb3f4f7c0 error 4 in libasound.so.2.0.0[7f64fffbf000+ea000]


After this happens, normal users cannot play sound. They receive the same error you got.

For me, the immediate workaround was simple. All I had to do was play audio (or a video with audio) as user root. Just a second is enough. When that program closes, it leaves the fd in a workable state. After this, all users can play audio as normal.

I would speculate that Timidity, as a daemon, is running as root. When it crashes, it leaves the fd in a state that a normal user cannot resolve. Having root open it and close it again returns things to normal. What I don't really understand is precisely why it doesn't recover gracefully from this kind of crash.

For me, the long-term fix was to realize that I really never play MIDI files and don't need Timidity. I've removed it from my system.
Back to top
View user's profile Send private message
frostschutz
Advocate
Advocate


Joined: 22 Feb 2005
Posts: 2724
Location: Germany

PostPosted: Mon May 02, 2016 6:55 pm    Post subject: Reply with quote

I recently got a lot of file descriptor in a bad state errors from ALSA as well. Either something in the alsa libraries changed, or it was the kernel.

Sound would work for a while until suddenly mplayer would no longer be able to produce sound.

My workaround was to run aplay [while sound was working] and stop the process with CTRL-Z, and leave the stopped process around forever.

Code:

$ nice aplay -c 2 -t raw -r 44 < /dev/zero
Playing raw data 'stdin' : Unsigned 8 bit, Rate 44000 Hz, Stereo
^Z
[1]+  Stopped                 nice aplay -c 2 -t raw -r 44 < /dev/zero


That way it seems the alsa device is always in use and never goes into bad state, whatever that means.
Back to top
View user's profile Send private message
causality
Apprentice
Apprentice


Joined: 03 Jun 2006
Posts: 171

PostPosted: Mon May 02, 2016 7:15 pm    Post subject: Reply with quote

Frost, when you run the command "dmesg" (which may require root, depending on your kernel config) and look at the output, did you see any segfaults involving libasound? Libasound is part of the media-libs/alsa-lib package, and it's used by applications to access the lower-level alsa system provided by the kernel.

If your terminal output is colorized, then this type of segfault will be colored red (in the output of dmesg) so you can easily find it. At least, for me it works that way running it in Konsole. Of course you can always try grep.

If you do have such a segfault, the program involved may be the root cause of the problem.
Back to top
View user's profile Send private message
frostschutz
Advocate
Advocate


Joined: 22 Feb 2005
Posts: 2724
Location: Germany

PostPosted: Mon May 02, 2016 8:34 pm    Post subject: Reply with quote

Nope, sorry. Seems there are various possible causes for a bad alsa file descriptor... and it seems its treated differently depending whether one program is using audio exclusively, or multiple programs sharing.
Back to top
View user's profile Send private message
causality
Apprentice
Apprentice


Joined: 03 Jun 2006
Posts: 171

PostPosted: Tue May 03, 2016 12:51 am    Post subject: Reply with quote

This is speculation on my part as it's been a long while since I've had to delve into the nitty-gritty of it... but having said that ...

Unless you have program using the old OSS interface, they *should* all be able to share using the ALSA interface. ALSA includes the dmix plugin, which you generally don't need to configure or go out of your way to enable. It should "just work". I've been using Linux since around 1996, and I haven't had a program monopolize the sound device since the days of OSS (at that time it was called /dev/dsp and it could indeed be locked). I'm not saying this cannot possibly happen with straight ALSA, only that it's not normal behavior and suggests some sort of fault condition.

If you're running pulseaudio this might be different for you, depending on how it's configured. I'm not sure about that. I just use straight ALSA myself.

Hopefully someone more knowledgable than myself will step in on this point.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Multimedia All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum