On 11 March 2003, Guido van Rossum said:
Great! I wonder if you have any thoughts on why running test_ossaudiodev hangs when run on Linux Red Hat 7.3? I'm currently using a 2.4.18-24.7.x kernel. I have no idea what other info would be useful to debug this.
The most obvious cause is that some other process has the audio device open, and your audio {hardware, device driver} only allows one at a time.
If you're running one of those newfangled GUI environments like KDE or GNOME, it's quite likely that the esound or aRTSd (however you spell it) daemon started when you logged in, and is thus blocking all access to your /dev/dsp. This sucks, but IMHO it's not ossaudiodev's job to know about esound and similar.
One way to test this is to take your system down to single-user (or at least a console-only, no-X11 runlevel) and then try running test_ossaudiodev.
Hmmm, it looks like calling open() with O_NONBLOCK helps. I know this does *not* affect later read()/write() -- there's a special ioctl() for non-blocking read/write -- but it *does* appear to fix blocking open(). At least for me it turned a second open() attempt on the same device from "hang" to "IOError: [Errno 16] Device or resource busy: '/dev/dsp2'".
Try this patch; if it works I'll check it in:
--- Modules/ossaudiodev.c 10 Mar 2003 03:17:06 -0000 1.24 +++ Modules/ossaudiodev.c 11 Mar 2003 15:56:24 -0000 @@ -131,7 +131,7 @@ basedev = "/dev/dsp"; }
- if ((fd = open(basedev, imode)) == -1) { + if ((fd = open(basedev, imode|O_NONBLOCK)) == -1) { PyErr_SetFromErrnoWithFilename(PyExc_IOError, basedev); return NULL; }
test_ossaudiodev.py will still need fixing to handle the EBUSY error, but at least this should prevent hanging on open().
Greg