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