The Two Ways You Can Play Digitized Sound On A Sound Blaster

The Sound Blaster was and is the original PC sound standard. Although it was
preceded by the AdLib card (which, for all intents and purposes, was the
first sound card ever released for the PC), the AdLib card was hampered by
the fact that it could only play FM MIDI sounds. It was officially incapable
of actual sound effects. Some people did come up with hacks to play something
resembling real audio on the AdLib (similar to the way people came up with a
way to play digitized sound on the PC's internal speaker), but the Sound
Blaster was made to play genuine digitized sound, thereby establishing itself
as the de facto PC sound standard, and remaining so until the late 1990s,
when cheap clones became so common that people didn't think much about having
a genuine Sound Blaster anymore.

If you used a program that played digitized sound on a Sound Blaster card,
you probably had to go through a configuration process that will be
well-remembered by anybody who played a lot of DOS games in the early 1990s.
Basically, you had to tell the program three key things about your Sound
Blaster: What I/O address it used, what IRQ it used, and what DMA channel it
used.

You might wonder what the point of all this would be. Why did the Sound
Blaster need an IRQ? The AdLib card didn't use an IRQ. And why in the world
did the Sound Blaster use a DMA channel? DMA channels were and are rarely
used by hardware; before the Sound Blaster, about the only piece of hardware
that would normally use DMA is a drive controller, and in fact, even today,
it's unlikely that anything other than your drive controller and sound device
use any DMA channels. Using I/O addresses is understandable (every device in
a PC needs an I/O address on which the device can exchange data with the
CPU), but why would a sound card need the other two types of resources?

As it turns out, technically, it doesn't. The Sound Blaster has a provision
for "direct" audio, also known as "direct DAC (Digital-to-Analog Converter)",
which allows the Sound Blaster to play sounds by receiving the data directly
from the CPU. The CPU simply writes the digitized audio data directly to the
Sound Blaster through an I/O address, and the card will play the sounds. This
programming technique sounds less complicated than having to go through IRQs
and DMA channels, so why was it rarely used in commercial games?

The simple answer is speed. Sound is a relatively high-frequency thing; to
make a sound effect seem realistic to the human ear, the sound must be
sampled several thousand times a second. Audio CDs play sounds with a
sampling rate of 44,100 hertz; that means a sample must be processed 44,100
times every second! Lower-quality sounds can get away with a lesser sampling
rate, but you can't realistically go below around 8,000 hertz without getting
pretty terrible sound; 8,000 hertz is often considered the low mark for
bottom-of-the-barrel sound. Yet even having to do something with sound 8,000
times every second will keep an electronic device busy.

In the 1980s, people were very concerned about their CPU cycles. CPUs ran at
several million cycles per second, but even at that speed, CPUs could never
seem to keep up with all the things that people were trying to do with them.
Thus, there was always a great concern for using CPU cycles as efficiently as
possible. Part of doing this was the practice of letting other devices with
some processing capability do a little processing of their own. For example,
in the very early days of microcomputers, programmers often concerned
themselves with what their disk drives were doing. In those now-distant
times, programmers might write routines to manually control the positions of
a disk drive's heads so that the heads would be in the right place at the
right time to "catch" a certain portion of the disk as it spun beneath the
heads. Today, such programming practices are nearly forgotten, as disk drives
are controlled by dedicated controller chips whose whole job is to look after
the drive; the CPU no longer has to concern itself with where the drive heads
are, that's the drive controller's job.

In a similar way, video and audio have tremendous data demands; the amount of
information needed to convey realistic-looking video or realistic-sounding
audio is huge. To require a computer's CPU to process all that information
would take away significantly from how many CPU cycles are available to do
all the number-crunching that the CPU has to do. So in the 1990s, video
hardware acceleration became commonplace: The practice of offloading much
video-processing work to the graphics controller, so that the CPU didn't need
to perform all the calculations associated with video rendering.

In the same vein, the Sound Blaster card (and virtually all major sound cards
today) have provisions for audio processing which allow a great load to be
lifted off the CPU. Audio is not only demanding in terms of how much data it
requires; it's also very demanding in terms of timing precision. If you wait
a fraction of a second too long in playing an audio sample, the audio will
sound distorted and scratchy. A computer CPU always has a lot of things going
on, and it may not be able to react at precisely the correct moment to
process the next audio sample. Therefore, not only does direct DAC audio eat
up a lot of CPU time, it also often requires programmers to do some funny
fiddlings with CPU timings to make sure the CPU can stay in time with the
audio. Considering all these complications, it's little wonder that
programmers usually opted to play digitized sound using a technique that
largely bypassed the CPU, and allowed software to more directly interact with
the sound card. IRQs and DMA channels give software more control over timings
and data paths, and although they still require some cooperation from the
CPU, they considerably lighten the processing load that the CPU must bear.

So this explains why the IRQs-and-DMA technique of playing digitized sound on
Sound Blaster cards (and indeed, sound cards in general) was and is the
preferred way of playing audio. It's somewhat more complicated than just
sending audio directly to the sound card, but good programmers rarely shy
away from a better technique just because it's more complicated.