Sound boards today come in two main types: FM synthesis and wavetable. The former is exemplified by the classic SoundBlaster 8-bit and 16-bit boards. They can play back digitally-recorded sounds (Star Trek's Mister Tuvok saying " Warp 3, engage" for instance) and can produce music from MIDI files played from OS/2, Windows, etc., by combining various sine waves to roughly emulate the sounds of assorted instruments. Wavetable boards can almost always also play back digital sounds, but they produce MIDI sounds by using a "wavetable" -- digital samples of instruments, or simulations thereof, recorded in ROM (or sometimes in RAM, loaded from a disk file) on the board. Thus, a wavetable board will sound much better than an FM synthesis board when playing the music files in many multimedia games, or if you use music composition software on the computer; but wavetable boards don't have any necessary advantage when playing digitally-recorded sounds. Wavetable boards can also differ from each other, sometimes substantially, in the quality of their samples.
The features of a sound board, however, require drivers in order to work. OS/2 drivers for many wavetable boards don't support the wavetable features from OS/2, so the MIDI music used in Galactic Civilizations 1.0, for instance, won't sound any better than on an FM synthesis board, if it plays at all. OS/2 drivers for many boards (of both types) also provide only limited access to the sound board for DOS and Windows programs, or such access will disrupt the OS/2 drivers. Much of my quest involved attempting to extract straight answers to the question of whether various features are supported under OS/2.
When used to describe a sound card, the number of bits (e.g., "8-bit" or "16-bit") almost always refers to the resolution of the audio samples when recording or playing back .WAV (or other digital audio) files. The number of bits does not normally refer to the width of the data bus used to connect the sound card to the computer, though the two numbers may happen to be the same. (ISA-bus cards use an 8- or 16-bit bus width, while VLB and PCI cards use a 32-bit bus width, though PCI itself allows for up to 64-bit, which isn't used on most PCI cards.) In fact, a 16-bit sound card can use an 8-bit (short) ISA slot or (in principle) a 32-bit PCI slot (see below concerning PCI sound cards).
Many sound cards include a number in their name, and consumers often interpret this as referring to the bit width of the sound samples. Sometimes this doesn't lead the consumer astray (e.g., the Creative Labs SoundBlaster-16 is a 16-bit sound card); but as often it does, particularly with higher-end boards. For instance, the Creative Labs SoundBlaster-32 series does not use a 32-bit sample size. In the case of the SB-32, the "32" officially refers to the number of simultaneous MIDI voices the card can handle. In fact, few sound cards have anything greater than 16-bit recording or playback capacity, and even if they did it would likely make little or no difference in the overall sound quality. Audio CDs, for instance, use 16-bit recording, and only the most demanding audiophiles complain about the quality of audio CDs.
When audiophiles do complain about this, the complaints are usually targeted at the sample rate (measured in kHz, frequently a multiple of 11kHz for sound cards), which typically goes as high as 44kHz for sound cards (this is also the rate at which audio CDs are sampled). A healthy human ear can hear frequencies of up to about 20kHz, but to record a pure 20kHz tone, it's necessary to have a sample rate of twice that, in order to "catch" both the high and the low point of the sound wave; recorded digitally at 20kHz, a 20kHz tone would vanish, since the sample would record the same point in the wave's cycle on each pass. Thus, a 40kHz sample rate can record a 20kHz tone, though it may not be a 100% faithful rendition of that tone. To record subtle differences in high sounds, an even higher sampling rate is required, hence the audiophiles' gripes about CDs. The same logic applies to computer sound cards, of course.
As mentioned above, many sound boards today are "Windows Sound System" compatible for digitized audio; but these boards also often require initialization software before they'll work. It seems that a handful of companies, such as OPTi and Crystal Semiconductor, provide the chipsets used in most sound boards. A given sound board may integrate chips or chipsets from multiple manufacturers to work in a specified way. For instance, the popular OPTi 928 and 929 chipsets provide interface support for the actual sound-producing chips from Yamaha, Crystal Semiconductor, and others. Drivers for one board will often work with boards bearing other brand names. The situation is similar to, but more chaotic than, the situation with video boards, in which companies such as Diamond and STB make use of chipsets from companies such as Tseng and S3. OS/2 uses drivers for the chipsets, and the video board brand itself serves largely to confuse people about this. I try to cover sound boards by both brand name and chipset in this document. If you're looking for drivers for an existing board, be aware that a listing for an unrelated-sounding board may have the information you require. As with video boards, but more so, it's not completely safe to assume that two boards using the same chipset will work equally well under OS/2, so if you've any doubts, try posting a question to comp.os.os2.multimedia and/or contact the board's manufacturer.
Recently, sound boards have begun appearing using DSP (digital signal processing) technology. DSPs are general-purpose processing chips that can be used in a number of applications. For instance, DSPs are used in certain types of modems, such as US Robotics and ZyXEL 14,400 bps and faster models. IBM's Mwave chips are DSPs that are being used in sound boards which can usually also be used as modems. Most such extra-flexible sound boards don't yet have much in the way of OS/2 driver support, however (though the IBM Multimedia Modem Plus and a few other Mwave boards are exceptions to this rule). Also, note that the presence of a DSP doesn't necessarily make the board unusually versatile; some DSPs (such as Ensoniq's OTTO) are still used as little more than special-purpose sound chips. Such boards do often have various sound effect options which aren't present on lower-end boards, though.
Most sound boards don't allow playing more than one sound file at a time. In a multitasking OS such as OS/2, it is of course possible that two programs will want to play sound files at once, and this generally isn't possible, at least not with the current drivers. Similarly, if you install Windows sound drivers, these generally "take over" the card when you run any Windows program, unless you select "none" for the AUDIO_ADAPTER_SHARING option in the Settings notebook for a program. This happens whether or not the program is actually playing sounds. The MediaVision ProAudio series boards do have two "channels," and it's possible to assign the SoundBlaster-compatible channel to Windows and the PAS "native" channel to OS/2, for a limited solution to this problem. (Note, however, that many people have problems configuring this properly.) Also, at least some boards allow playing MIDI and digitized sounds simultaneously, and most permit playing an audio CD through the computer's speakers while performing other audio functions. The latest (version 2.0) OPTi drivers allow playing OS/2 sounds when a Windows session is open, but not true concurrency of OS/2 and Windows sounds. These drivers reportedly work by having the OS/2 and Windows drivers "talk" to each other to avoid conflicts. Boards based on IBM's Mwave chip allow OS/2 sounds to play when the Windows sound drivers are loaded, and even to play more than one .WAV file simultaneously, though two MIDI files generally exceeds the board's processing capacity. In theory, drivers could be written to get around this problem in a more general way, as the OPTi drivers do. I recently heard some rumblings that OS/2's MMPM/2 may be undergoing revisions which may make this more common in future versions of OS/2, but this has not made it into Warp 4.0.
"Full duplex," applied to sound cards, refers to the ability to simultaneously record and play back sounds. Unfortunately, most boards don't have OS/2 drivers that support full duplex. The primary exceptions to this rule are Mwave boards, AMD InterWave-based boards such as the Gravis UltraSound PnP, and boards based on the Crystal Semiconductor CS-423x series, though some of these present limitations of various types. Full duplex's main appeal is in telephone applications. Unfortunately, VTD in Warp 4.0 seems to disable a sound card's full duplex ability, so full duplex won't do much good for retaining system sounds when VTD is active, though in theory it could.
Modern sound boards frequently have interfaces for one or more types of CD-ROMs. As I don't use the sound card's CD interface, I wasn't very concerned with this in my own search, but I've included a note for each of the boards I mention on what types of interfaces it has. Interfaces can be SCSI (general, for any SCSI CD-ROM drive), IDE (general, for any IDE/EIDE/ATAPI CD-ROM), or proprietary (for older Sony, Panasonic, Mitsumi, etc. drives). In any case, you'll need a driver for the interface and/or CD-ROM drive. OS/2 comes with drivers for most of the proprietary standards and for IDE drives, though I can't guarantee these will work with all boards using these interfaces. OS/2 may or may not come with a driver for a specific SCSI interface. As with the sound features, many boards require initialization software be run before the CD-ROM interface becomes active, so this may be a prerequisite for using such interfaces under OS/2. Sound card CD-ROM interfaces can generally be disabled (or simply not initialized), and so won't cause problems if you've already got another type of CD-ROM.
Sound boards require interrupts (IRQs) in order to function. Simple boards, such as many SoundBlaster boards, require only a single IRQ (generally #5). More complex boards may require two or more IRQs for the sound board, and frequently another for the CD-ROM interface, if it's being used. The miroCONNECT 34 wave board takes up to four IRQs, including one for its modem features, and I assume other Mwave boards would do the same. Thus, if you want an advanced wavetable board, be sure you've got enough free IRQs, and IRQs the board can use. Similarly, sound boards use address spaces for I/O and DMA channels. Most modern boards use software to set the IRQs, etc., that they use.
Some FM synthesis boards include a connector for a wavetable daughter card, which allows one to upgrade to wavetable abilities relatively painlessly. I haven't seriously investigated such daughter cards, though, and don't know much about them. These daughter cards typically cost $60-$200. The wavetable features may or may not be automatically utilized by the OS/2 drivers for the main board. I've heard that recent SoundBlaster drivers include a CONFIG.SYS option ("/EXT") to force use of the wavetable daughtercard. Therefore, a true SoundBlaster in combination with a wavetable daughtercard can make a good choice for wavetable sound under OS/2. There are also a few wavetable-only boards available that can be used in conjunction with an existing FM synthesis board. These would require IBM's MPU-401 driver to function properly, but if you use a sound board with its own FM synthesis MIDI capability (such as most SoundBlasters), the two drivers may conflict.
A microphone is a necessary component if you intend to use a sound card for speech recognition, for an Internet telephony application, or simply to record your own wonderful self. ;-) Unfortunately, sound cards are often finicky about what types of microphones they require. OS/2 Warp 4.0 comes with an Andrea microphone and an adapter, and this microphone can be made to work with most sound cards by using it either with or without the adapter. If you're having problems getting adequate input from your microphone, check http://www.shure.com/app-soundcard.html, especially if you have a Shure microphone. This site has lots of useful information on microphone specifications and what different sound cards require.
In theory, PCI-based sound boards could get around some of the IRQ hogging inherent in advanced ISA-based boards. After quite a few moons of promises, PCI sound cards finally seem to be shipping in quantity and at affordable prices; Ensoniq, S3, ESS, Crystal Semiconductor, VLSI, and probably others have PCI-based sound cards or chipsets. Unfortunately, as of December, 1997, I don't know of any PCI sound card that has OS/2 driver support; none of the above have any information about OS/2 drivers for their PCI products that I could find on their web sites. The PDF spec sheet for the VLSI Songbird does mention OS/2 drivers, but I could not locate them on their web site, nor on their ftp site.
Most new sound cards these days seem to have the words "Plug-and-Play" (PnP, for short) plastered all over them. The theory is that such boards will auto-configure, and they often do so when combined with PnP-aware motherboards and under Win95; but for OS/2 users, they range from a curse to a minor advance over their jumper-laden predecessors. Fundamentally, as always, the problem lies in the drivers, which may not exist for OS/2. There are also sometimes problems with the motherboard. Unfortunately, non-PnP sound cards have gone the way of the Dodo, so OS/2 users are pretty much stuck with whatever the manufacturers care to sell. This makes good driver support all the more important, particularly if you've got an older motherboard that may not give good (or any) PnP configuration options.