Change to ossaudiodev setparameters() method
Currently, oss_audio_device objects have a setparameters() method with a rather silly interface: oss.setparameters(sample_rate, sample_size, num_channels, format [, emulate]) This is silly because 1) 'sample_size' is implicit in 'format', and 2) the implementation doesn't actually *use* sample_size for anything -- it just checks that you have passed in the correct sample size, ie. if you specify an 8-bit format, you must pass sample_size=8. (This is code inherited from linuxaudiodev that I never got around to cleaning up.) In addition to being silly, this is not the documented interface. The docs don't mention the 'sample_size' argument at all. Presumably the doc writer realized the silliness and was going to pester me to remove 'sample_size', but never got around to it. (Lot of that going around.) So, even though we're in a beta cycle, am I allowed to change the code so it's 1) sensible and 2) consistent with the documentation? Greg -- Greg Ward <gward@python.net> http://www.gerg.ca/ Sure, I'm paranoid... but am I paranoid ENOUGH?
Yes. I like silliness in a MP skit, but not in my APIs. :-) --Guido van Rossum (home page: http://www.python.org/~guido/)
[me, on ossaudiodev.setparameters()]
[Guido]
Yes. I like silliness in a MP skit, but not in my APIs. :-)
OK, done. I've also beefed up the test script a bit. So, once again, if you have a Linux or FreeBSD system with working sound card, can you run ./python Lib/test/regrtest.py -uaudio test_ossaudiodev ...preferably before and after a "cvs up && make" to see if things are better, worse, or unchanged? Greg -- Greg Ward <gward@python.net> http://www.gerg.ca/ All the world's a stage and most of us are desperately unrehearsed.
Did you check in the changes to ossaudiodev? A cvs update gave me new test files: P Lib/test/test_ossaudiodev.py P Lib/test/output/test_ossaudiodev but no new C code, and now I get this error when I run the above test: $ ./python ../Lib/test/regrtest.py -uaudio test_ossaudiodev test_ossaudiodev test test_ossaudiodev crashed -- exceptions.TypeError: setparameters() takes at least 4 arguments (3 given) 1 test failed: test_ossaudiodev $ Before the cvs update, the test produced some audio and then hung; when I interrupted, here's the traceback: Traceback (most recent call last): File "../Lib/test/regrtest.py", line 974, in ? main() File "../Lib/test/regrtest.py", line 264, in main ok = runtest(test, generate, verbose, quiet, testdir) File "../Lib/test/regrtest.py", line 394, in runtest the_package = __import__(abstest, globals(), locals(), []) File "/mnt/home/guido/projects/trunk/Lib/test/test_ossaudiodev.py", line 96, in ? test() File "/mnt/home/guido/projects/trunk/Lib/test/test_ossaudiodev.py", line 93, in test play_sound_file(data, rate, ssize, nchannels) File "/mnt/home/guido/projects/trunk/Lib/test/test_ossaudiodev.py", line 56, in play_sound_file a.write(data) --Guido van Rossum (home page: http://www.python.org/~guido/)
On 29 May 2003, Guido van Rossum said:
Did you check in the changes to ossaudiodev?
Oops! I did now -- thanks. Please try again. Greg -- Greg Ward <gward@python.net> http://www.gerg.ca/ I just read that 50% of the population has below median IQ!
Did you check in the changes to ossaudiodev?
Oops! I did now -- thanks. Please try again.
Alas, no change. Still some squeaks from the speaker followed by a hanging process: Traceback (most recent call last): File "../Lib/test/regrtest.py", line 974, in ? main() File "../Lib/test/regrtest.py", line 264, in main ok = runtest(test, generate, verbose, quiet, testdir) File "../Lib/test/regrtest.py", line 394, in runtest the_package = __import__(abstest, globals(), locals(), []) File "/mnt/home/guido/projects/trunk/Lib/test/test_ossaudiodev.py", line 119, in ? test() File "/mnt/home/guido/projects/trunk/Lib/test/test_ossaudiodev.py", line 116, in test play_sound_file(data, rate, ssize, nchannels) File "/mnt/home/guido/projects/trunk/Lib/test/test_ossaudiodev.py", line 58, in play_sound_file dsp.write(data) KeyboardInterrupt --Guido van Rossum (home page: http://www.python.org/~guido/)
On 29 May 2003, Guido van Rossum said:
Alas, no change. Still some squeaks from the speaker followed by a hanging process:
Well, my recent ossaudiodev changes wouldn't have changed anything if ossaudiodev is completely hosed. However, I've finally gotten around to writing my pure C OSS test program. It's checked in under sandbox/audiotest. Please give it a try! cd nondist/sandbox cvs up -dP cd audiotest make && ./audiotest If *that* doesn't give sensible results, then we can't blame ossaudiodev for the fact that it doesn't work on your box. Err, the same goes for anyone with a Linux, FreeBSD, or OpenBSD box and audio hardware: can y'all give the above a try and let me know how it works for you? Especially if you've had problems with ossaudiodev in the past (hello, Jeremy). I've tried to code to lowest-common-denominator audio hardware, but that's easier said than done. Greg -- Greg Ward <gward@python.net> http://www.gerg.ca/ And now for something completely different.
That gives sensible results. The mystery continues... But I wonder if there's a difference between my home and my work box? The ossaudiodev test runs fine on my home box now, but it hung on my work box last week; I seem to recall that it failed on my home box before your last fix to the C module. --Guido van Rossum (home page: http://www.python.org/~guido/)
Indeed, on my work box running ./audiotest says: opening /dev/dsp ... done audiotest: error: /dev/dsp: unable to set sample format to 8 (got 16) ls -l /dev/dsp gives: crw------- 1 guido root 14, 3 Apr 11 2002 /dev/dsp which is about the same as it is on my home box. Adding the x permission doesn't change a thing. Maybe the audio hardward on the work box simply isn't capable of doing anything besides 16-bit samples? According to hwbrowser, it is 82801AA AC'97 Audio Manufacturer: Intel Corp. Driver: i810_audio Device: N/A The home box (which works) is CRD-8400B Manufacturer: Unknown Driver: ignore Device: /dev/hdc How's that for differences. :-0 --Guido van Rossum (home page: http://www.python.org/~guido/)
That's the same as I've got in my Dell Latitude (running RH7.3) and as far as I can tell, it's "give me 16 bit samples or I give you squeaky chipmunk voice" (or an error). I'm hoping that upgrading to RH9 will give a newer audiodriver (alsa, hopefully) that'll fix this. (waiting for vmware upgrade to support RH9 first...) Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
On 02 June 2003, Guido van Rossum said:
Right, that's not a permissions problem. It means that audiotest.c tried to set your hardware to unsigned 8-bit samples: fmt = AFMT_U8; /* 8 */ ioctl(fd, SNDCTL_DSP_SETFMT, &fmt); and the device driver refused, returning fmt == AFMT_S16_LE == 16 (signed 16-bit little-endian), which seems to be the *other* lowest-common-denominator audio format.
Maybe the audio hardward on the work box simply isn't capable of doing anything besides 16-bit samples? According to hwbrowser, it is
I suspect that is the case. The good news is that I've modified audiotest.c so it now takes command-line options to set the sample format, eg. audiotest -b 16 -s for signed, little-endian 16-bit samples. (Currently little-endian is hardcoded.) The bad news is that there's something wrong with my sine-wave generating code for 16-bit samples: I'm quite sure that both of the audio devices on my PC support both 8-bit and 16-bit audio, but the 16-bit sine waves produced by audiotest.c sound horribly wrong. I suspect a second pair of eyeballs is needed here. Can someone take a good hard look at nondist/sandbox/audiotest/audiotest.c, in particular the mkbuffer() and gen_sine() functions, and see if you can spot anything wrong? It's probably a silly arithmetic error indicating a subtle misunderstanding on my part, but I'm stumped.
Wow, I wonder what hwbrowser is smoking. I strongly advise you *not* to start writing audio data to /dev/hdc. ;-) Greg -- Greg Ward <gward@python.net> http://www.gerg.ca/ This quote intentionally left blank.
Trying this with the latest version gives: opening /dev/dsp ... done audiotest: error: /dev/dsp: unable to set number of channels to 1 (got 2)
When this happened to me in a previous life, the byte order was wrong.
What's /dev/hdc??? --Guido van Rossum (home page: http://www.python.org/~guido/)
On Tue, Jun 03, 2003, Guido van Rossum wrote:
What's /dev/hdc???
Your hard disk. (Or one of them, to be precise, though I'm not entirely positive Greg's correct -- I suspect that /dev/hdc might simply refer to one of the IDE channels.) -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "If you don't know what your program is supposed to do, you'd better not start writing it." --Dijkstra
On Thu, 29 May 2003, Greg Ward wrote:
With a CVS tree updated about 0520 AEST this morning (1920 UTC Sunday), on a FreeBSD 4.7 system test_ossaudiodev (with -v) outputs the following: test_ossaudiodev playing test sound file... elapsed time: 2.9 sec test test_ossaudiodev crashed -- exceptions.AttributeError: 'module' object has no attribute 'AFMT_S16_NE' Traceback (most recent call last): File "Lib/test/regrtest.py", line 394, in runtest the_package = __import__(abstest, globals(), locals(), []) File "/home/andymac/build/python-cvs/python-cvs/Lib/test/test_ossaudiodev.py", line 119, in ? test() File "/home/andymac/build/python-cvs/python-cvs/Lib/test/test_ossaudiodev.py", line 117, in test test_setparameters() File "/home/andymac/build/python-cvs/python-cvs/Lib/test/test_ossaudiodev.py", line 73, in test_setparameters config2 = (ossaudiodev.AFMT_S16_NE, 2, 44100) AttributeError: 'module' object has no attribute 'AFMT_S16_NE' 1 test failed: test_ossaudiodev The sound file plays correctly, but as I don't have amplified speakers on this box I don't get enough volume for hear it properly. AFMT_S16_NE is not defined in /usr/include/sys/soundcard.h (nor is it defined for FreeBSD 4.8), but definitions exist for both AFMT_S16_BE and AFMT_S16_LE. My automatic cvs update hasn't caught up with your sandbox audiotest utility yet. -- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac@bullseye.apana.org.au (pref) | Snail: PO Box 370 andymac@pcug.org.au (alt) | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia
On 02 June 2003, Andrew MacIntyre said:
Oops! Just checked in a fix to test_ossaudiodev.py that should fix this. Please try again.
My automatic cvs update hasn't caught up with your sandbox audiotest utility yet.
OK, let me know how it works when it has caught up... Greg -- Greg Ward <gward@python.net> http://www.gerg.ca/ Hold the MAYO & pass the COSMIC AWARENESS ...
participants (5)
-
Aahz
-
Andrew MacIntyre
-
Anthony Baxter
-
Greg Ward
-
Guido van Rossum