Loading...
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 | Soundcore Notes on Modular Sound Drivers and Soundcore Wade Hampton 11/20/1998 Purpose: ======== This document provides some general notes on the modular sound drivers and their configuration, along with the support modules sound.o, soundlow.o and soundcore.o. Note, some of this probably should be added to the Sound-HOWTO! Copying: ======== none History: ======== 0.1.0 11/20/1998 First version Modular Sound Drivers: ====================== Thanks to the GREAT work by Alan Cox (alan@lxorguk.ukuu.org.uk), [And Oleg Drokin, Thomas Sailer, Andrew Veliath and more than a few others - not to mention Hannu's original code being designed well enough to cope with that kind of chopping up](Alan) the standard Linux kernels support a modular sound driver. From Alan's comments in linux/drivers/sound/README.FIRST: The modular sound driver patches were funded by Red Hat Software (www.redhat.com). The sound driver here is thus a modified version of Hannu's code. Please bear that in mind when considering the appropriate forums for bug reporting. The modular sound drivers may be loaded via insmod or modprobe. To support all the various sound modules, there are three general support modules that must be loaded first: soundcore.o: Top level handler for the sound system, provides a set of functions for registration of devices by type. soundlow.o: Low-level sound drivers which are not part of OSS/Lite (Open Sound System), including SB32/AWE synthesizer, etc. sound.o: Common sound functions required by all modules. For the specific sound modules (e.g., sb.o for the Soundblaster), read the documentation on that module to determine what options are available, for example IRQ, address, DMA. Warning, the options for different cards sometime use different names for the same or a similar feature (dma1= versus dma16=). As a last resort, inspect the code (search for MODULE_PARM). INSMOD: ======= If loading via insmod, the common modules must be loaded in the order below BEFORE loading the other sound modules. The card-specific modules may then be loaded (most require parameters). For example, I use the following via a shell script to load my SoundBlaster: SB_BASE=0x240 SB_IRQ=9 SB_DMA=3 SB_DMA2=5 SB_MPU=0x300 # echo Starting sound /sbin/insmod soundcore /sbin/insmod soundlow /sbin/insmod sound # echo Starting sound blaster.... /sbin/insmod uart401 /sbin/insmod sb io=$SB_BASE irq=$SB_IRQ dma=$SB_DMA dma16=$SB_DMA2 mpu_io=$SB_MP MODPROBE: ========= If loading via modprobe, these common files are automatically loaded when requested by modprobe. For example, my /etc/conf.modules contains: alias sound sb options sb io=0x240 irq=9 dma=3 dma16=5 mpu_io=0x300 All you need to do to load the module is: /sbin/modprobe sb Sound Status: ============= The status of sound may be read/checked by: cat /proc/sound cat /dev/sndstat cat (anyfile).au >/dev/audio The status of the modules and which modules depend on which other modules may be checked by: /sbin/lsmod /sbin/lsmod should show something like the following: sb 26280 0 uart401 5640 0 [sb] sound 57112 0 [sb uart401] soundlow 208 0 [sound] soundcore 1968 8 [sb sound] Removing Sound: =============== Sound may be removed by using /sbin/rmmod in the reverse order in which you load the modules. Note, if a program has a sound device open (e.g., xmixer), that module (and the modules on which it depends) may not be unloaded. For example, I use the following to remove my Soundblaster (rmmod in the reverse order in which I loaded the modules): /sbin/rmmod sb /sbin/rmmod uart401 /sbin/rmmod sound /sbin/rmmod soundlow /sbin/rmmod soundcore Multiple Sound Cards: ===================== The sound drivers will support multiple sound cards and there are some great applications like multitrack that support them. Typically, you need two sound cards of different types. Note, this uses more precious interrupts and DMA channels and sometimes can be a configuration nightmare. I have heard reports of 3-4 sound cards (typically I only use 2). On my machine I have two sound cards (cs4232 and Soundblaster Vibra 16). By loading sound as modules, I can control which is the first sound device (/dev/dsp, /dev/audio, /dev/mixer) and which is the second. Normally, the cs4232 (Dell sound on the motherboard) would be the first sound device, but I prefer the Soundblaster. All you have to do is to load the one you want as /dev/dsp first (in my case "sb") and then load the other one (in my case "cs4232"). Warning: I have never been able to get two PnP sound cards of the same type to load at the same time. I have tried this several times with the Soundblaster Vibra 16 cards. OSS has indicated that this is a PnP problem.... If anyone has any luck doing this, please send me an E-MAIL. PCI sound cards should not have this problem. Sound Problems: =============== First RTFM (including the troubleshooting section in the Sound-HOWTO). 1) If you are having problems loading the modules (for example, if you get device conflict errors) try the following: A) If you have Win95 or NT on the same computer, write down what addresses, IRQ, and DMA channels those were using for the same hardware. You probably can use these addresses, IRQs, and DMA channels. B) Check (cat) /proc/interrupts, /proc/ioports, and /proc/dma. Are you trying to use an address, IRQ or DMA port that another device is using? C) Check (cat) /proc/sys/pnp (if this exists, you may need a kernel patch to get this device). D) Inspect your /var/log/messages file. Often that will indicate what IRQ or IO port could not be obtained E) Try another port or IRQ. Note this may involve using the PnP tools to move the sound card to another location. 2) If you get motorboating (the same sound or part of a sound clip repeated), you probably have either an IRQ or DMA conflict. Move the card to another address. This has happened to me when playing long files when I had an IRQ conflict. 3) Ask for help on the sound list or send E-MAIL to the sound driver author/maintainer. 4) Turn on debug in drivers/sound/sound_config.h (DEB, DDB, MDB). Configuring Sound: ================== There are several ways of configuring your sound: 1) Hardcoded in the kernel at compile time (not applicable when using sound modules). This was the OLD way! 2) On the command line when using insmod. 3) In /etc/conf.modules when using modprobe. 4) Via Red Hat's /usr/sbin/sndconfig program (text based). 5) Via the OSS soundconf program (with the commercial version of the OSS driver. And I am sure, several other ways. Anyone want to write a linuxconf module for configuring sound? For More Information (RTFM): ============================ 1) Information on kernel modules: linux/Documentation/modules.txt and manual pages for insmod and modprobe. 2) Information on PnP, RTFM manual pages for isapnp. 3) Sound-HOWTO and Sound-Playing-HOWTO. 4) OSS's WWW site at http://www.opensound.com. 5) All the files in linux/Documentation/sound. 6) The comments and code in linux/drivers/sound. 7) The sndconfig and rhsound documentation from Red Hat. 8) The Linux-sound mailing list: sound-list@redhat.com Contact Information: ==================== Wade Hampton: (whampton@staffnet.com) |