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?

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()]

...

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?

[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?

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/)

...

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.

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/)

...

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.

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.

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/)

On 02 June 2003, Andrew MacIntyre said:

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'

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 ...

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.)

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)

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.

When this happened to me in a previous life, the byte order was wrong.

...

The home box (which works) is

CRD-8400B Manufacturer: Unknown Driver: ignore Device: /dev/hdc ^^^^^^^^

Wow, I wonder what hwbrowser is smoking. I strongly advise you *not* to start writing audio data to /dev/hdc. ;-)

What's /dev/hdc??? --Guido van Rossum (home page: http://www.python.org/~guido/)