On my Mandrake 8.0 laptop I ran make test after grabbing the latest stuff from cvs and wound up with 145 tests OK. 1 test failed: test_linuxaudiodev 14 tests skipped: test_al test_cd test_cl test_dl test_gl test_imgfile test_largefile test_nis test_ntpath test_socketserver test_sunaudiodev test_unicode_file test_winreg test_winsound The linuxaudiodev test never seems to work for me (though I do hear an agonizing wail (is that supposed to be Homer Simpson?) from my laptop's speakers when it's run). The result is always: test test_linuxaudiodev crashed -- linuxaudiodev.error: (16, 'Device or resource busy') The socketserver test works when run manually. Skip
Neil Schemenauer writes:
Something has /dev/dsp or /dev/audio open. Are you playing MP3s or running something like esd?
This is exactly the problem I was having several months ago. I "solved" it by changing the permissions on the audio device: cj42289-a(.../python/linux); ls -lF /dev/dsp crw-rw---- 1 root audio 14, 3 Sep 27 2000 /dev/dsp cj42289-a(.../python/linux); ./python ../Lib/test/regrtest.py test_linuxaudiodevtest_linuxaudiodev test test_linuxaudiodev skipped -- (13, 'Permission denied', '/dev/dsp') 1 test skipped: test_linuxaudiodev As a side effect, the machine no longer makes that horrid screeching sound. ;-) -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation
>> test test_linuxaudiodev crashed -- linuxaudiodev.error: (16, 'Device >> or resource busy') Neil> Something has /dev/dsp or /dev/audio open. Are you playing MP3s Neil> or running something like esd? Nope, not that I'm aware of. I poked around ps auxww output but didn't find anything that looked like an audio server. /dev/dsp and /dev/audio* are owned by user "skip", group "audio". My usual login is "skip" and I am in group "audio". The test succeeds outside of X but no sound is produced. Skip
Fred experiences this too with Mandrake on his Dell laptop, and before someone hacked the extension module I experienced it on a Dell desktop with Red Hat too -- no MP# players. The wail that Skip hears is the first second of "Nobody expects the Spanish inquisition". I think that different audio hardware has different Linux drivers that act differently, and the extension module doesn't know how to properly wait until enough buffer space is available with some drivers. --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido> Fred experiences this too with Mandrake on his Dell laptop, and Guido> before someone hacked the extension module I experienced it on a Guido> Dell desktop with Red Hat too -- no MP# players. Nice to know I'm not alone. I also have Mandrake 8.0 on a Dell laptop. Since it's something the wizards know about, I won't pursue it further. Skip
On 02 August 2001, Skip Montanaro said:
I am pleased-as-punch to report that test_linuxaudiodev *finally* works for me, both in 2.2a1 and the CVS as of this afternoon (after Tim's big merge). Also, the rest of the test suite seems to have passed just fine for me with the latest CVS; this is a Progeny Debian 1.0 system (pretty close to Debian 2.2 stable). ("Seems to have passed" because there's some aborted work from a year or so ago where I was trying to fix the lexer's handling of line termination. Gave up in despair -- brain too small -- but I still have non-working tokenizer tests sitting in my CVS working dir. Sigh.) Greg -- Greg Ward - programmer-at-large gward@python.net http://starship.python.net/~gward/ Always look on the bright side of life.
Neil Schemenauer writes:
Something has /dev/dsp or /dev/audio open. Are you playing MP3s or running something like esd?
This is exactly the problem I was having several months ago. I "solved" it by changing the permissions on the audio device: cj42289-a(.../python/linux); ls -lF /dev/dsp crw-rw---- 1 root audio 14, 3 Sep 27 2000 /dev/dsp cj42289-a(.../python/linux); ./python ../Lib/test/regrtest.py test_linuxaudiodevtest_linuxaudiodev test test_linuxaudiodev skipped -- (13, 'Permission denied', '/dev/dsp') 1 test skipped: test_linuxaudiodev As a side effect, the machine no longer makes that horrid screeching sound. ;-) -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation
>> test test_linuxaudiodev crashed -- linuxaudiodev.error: (16, 'Device >> or resource busy') Neil> Something has /dev/dsp or /dev/audio open. Are you playing MP3s Neil> or running something like esd? Nope, not that I'm aware of. I poked around ps auxww output but didn't find anything that looked like an audio server. /dev/dsp and /dev/audio* are owned by user "skip", group "audio". My usual login is "skip" and I am in group "audio". The test succeeds outside of X but no sound is produced. Skip
Fred experiences this too with Mandrake on his Dell laptop, and before someone hacked the extension module I experienced it on a Dell desktop with Red Hat too -- no MP# players. The wail that Skip hears is the first second of "Nobody expects the Spanish inquisition". I think that different audio hardware has different Linux drivers that act differently, and the extension module doesn't know how to properly wait until enough buffer space is available with some drivers. --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido> Fred experiences this too with Mandrake on his Dell laptop, and Guido> before someone hacked the extension module I experienced it on a Guido> Dell desktop with Red Hat too -- no MP# players. Nice to know I'm not alone. I also have Mandrake 8.0 on a Dell laptop. Since it's something the wizards know about, I won't pursue it further. Skip
On 02 August 2001, Skip Montanaro said:
I am pleased-as-punch to report that test_linuxaudiodev *finally* works for me, both in 2.2a1 and the CVS as of this afternoon (after Tim's big merge). Also, the rest of the test suite seems to have passed just fine for me with the latest CVS; this is a Progeny Debian 1.0 system (pretty close to Debian 2.2 stable). ("Seems to have passed" because there's some aborted work from a year or so ago where I was trying to fix the lexer's handling of line termination. Gave up in despair -- brain too small -- but I still have non-working tokenizer tests sitting in my CVS working dir. Sigh.) Greg -- Greg Ward - programmer-at-large gward@python.net http://starship.python.net/~gward/ Always look on the bright side of life.
participants (5)
-
Fred L. Drake, Jr. -
Greg Ward -
Guido van Rossum -
Neil Schemenauer -
Skip Montanaro