On 02 June 2003, Guido van Rossum said:
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.
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.
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. ;-) Greg -- Greg Ward <gward@python.net> http://www.gerg.ca/ This quote intentionally left blank.