[Python-Dev] Change to ossaudiodev setparameters() method

Greg Ward gward@python.net
Mon, 2 Jun 2003 21:41:24 -0400


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.