Comment 53 for bug 159258

This bug hits me *every single day*. I play mp3's (usually internet radio using rhythmbox or songbird) and use firefox extensively, reading lots of pdf documents with xpdf. After some time, xpdf will block the sound device and I have to go track down which pid is blocking it and kill all the documents I have open (usually I have several). The choice by ubuntu to use pulseaudio seems to make the situation worse. I usually find it's the first thing I have to kill, then it's xpdf sessions, or firefox itself.

This may be a deeper bug. Clearly it works with 2 pid's holding the same file handle, but shows up as more and more pid's hold the filehandle. Exactly which circumstance leads to the sound device being blocked? The reported programs which cause this (xpdf, evince, gv) do not read or write the sound device at all. So why does it get blocked in the first place?

Closing the file handle may or may not fix the problem depending on the ultimate reason that the sound device gets blocked. Has anyone actually tested the theory that it's just holding file handles that causes the problem? (e.g. with a helper script as suggested above?)