I have a couple of Dell Precision 210 workstations with CS4236B sound
chips. One is running Red Hat 6.1 and a self-built, unpatched kernel
2.2.12. It uses the following hand-tweaked module configuration:
alias sound-slot-0 cs4232
alias sound-service-0-3 sound-slot-0
alias synth0 opl3
options cs4232 io=0x534 irq=5 dma=1 dma2=0
options opl3 io=0x388
The second box has Red Hat 6.0, including Red Hat's patched kernel
2.2.5. It uses the following module configuration, automatically
generated by Red Hat's "sndconfig" tool:
alias sound cs4232
pre-install sound insmod sound dmabuf=1
alias midi opl3
options opl3 io=0x388
options cs4232 io=0x534 irq=5 dma=1 dma2=0 \
mpuio=0x330 mpuirq=5 synthirq=-1 synthio=-1
In both cases, the IO/IRQ/DMA selections are also reflected in a PnP
configuration file processed by "isapnp" at boot time.
When any application starts to send sound to the chip, a loud and
rather harsh "click" or "pop" comes out first. After that pop, sound
continues to flow normally as long as the application keeps writing
data. If the audio data flow stops, the pop will again appear the
next time the audio data flow resumes.
The pop appears when using either the "/dev/audio" or "/dev/dsp"
interface, no matter what the overlying application: xmms, sox, esd,
kwmsound, you name it. It does not appear, though, when using
playmidi to play MIDI files through "/dev/sequencer".
The pop even appears if I try to record sound rather than play it!
"cat /dev/dsp >/dev/null" and "cat /dev/audio >/dev/null" both produce
the pop.
The pop is not associated with module loading. Even after the modules
are loaded, each time an application starts to emit sound data, the
introductory pop comes out first.
The pop is not associated with simply opening "/dev/dsp" or
"/dev/audio". The Enlightened sound daemon (esd) keeps "/dev/dsp"
open the entire time it is running. But each time it plays a new
sound clip, the harsh pop comes first. This ends up being
particularly maddening when using a desktop configuration that plays
accent sounds in response to user actions. "pop boing", "pop
booda-booda", "pop whoosh" ... you get the picture.
This does not appear to be a hardware failure, as both boxes suffer
from the same problem. Furthermore, the IO/IRQ/DMA settings were
copied from working Windows NT installations on the same boxes, and
audio under NT does not exhibit this behavior.
Any ideas?
