This seems to be a case of not knowing what I don't know. There is a wheezy system that is routinely updated and sound mostly works normally with /dev/dsp being a CS4237B built-in sound card and /dev/dsp1 is a usb-based sound card that works just like it should.
I did need to add snd_cs4236 and snd_usb_audio to /etc/modules to insure that the cs4237B is always /dev/dsp and /dev/dsp1 is always the usb sound card but here is the issue: If I call mplayer which wants /dev/dsp to be Card 0, it usually plays the file but not always. On some types of .wav files, /dev/dsp refuses to play the file and claims that /dev/dsp is busy even though lsof doesn't show /dev/dsp as being open. Other types of .wav file play perfectly. I recently used text2wav which is part of the festival speech synthesizer suite and it produced a .wav file called u.wav which was made of 16-bit littleendian samples that should just play. The mplayer application complained as follows: [AO_ALSA] Unable to set samplerate-2: Invalid argument Failed to initialize audio driver 'alsa' [AO OSS] audio_setup: Can't open audio device /dev/dsp: Device or resource busy Failed to initialize audio driver 'oss' Could not open/initialize audio device -> no sound. If I used aplay, the message reads: Playing WAVE 'u.wav' : Signed 16 bit Little Endian, Rate 16000 Hz, Mono That same u.wav file played perfectly if I used /dev/dsp1. I also get many .wav or .mp3 files to play through /dev/dsp so the inability to play some wav files is related to their content or header format. I actually posted a message last week in which I thought the problem had to do with a program I was writing whose output was a .wav stream but now I realize that it was the problem I have been mentioning in this post. Any ideas as to why all files play through Card 1 but some .wav files refuse to play through Card 0? It's usually all or nothing. Thank you for all relevant suggestions. Martin McCormick