Summary:
Real Sound Blasters don't need a driver to initialise or support them. Clones may need one-time initialisation. Exotic cards may need memory-resident translation layers.
Games use a collection of per-card drivers to 'talk' to the appropriate hardware interfaces. These can be hard-coded into the game, or a collection of external files like in HMI or Miles.
Depending on your situation, one or both of these may apply.
To play Halloween Harry on a real Sound Blaster, no extra files are needed. The SB support is hard-coded.
To play Theme Hospital on a SB Live PCI under MS-DOS, the game uses a third-party Miles driver to abstract the SB card. The card itself requires a Live driver to imitate the hardware interface of an older SB card.
All the answers given here so far are correct, for different scenarios. What may confuse is that there are two distinct phases that both could correctly be called 'drivers'. Let me describe what I mean:
Pretty much everything here applies to both digitised audio output and AdLib/OPL2/OPL3 support equally.
1) Initialisation and support to -provide- the interface
Legitimate, first-party Sound Blaster series of cards are programmed directly through I/O ports. There's a chip on-board known as the 'DSP'* which handles all the data movement to and from the card. If you have a real Sound Blaster, and the game knows how to 'talk Sound Blaster' to the DSP using the interface described in the Sound Blaster Series Hardware Programming Guide then that's all that's needed.
*(Not to be confused with a 'DSP' in later usage which typically provides a programmable effect like reverb.)
If you have a clone card or a third-party 'compatible card', then one of the following applies:
- The clone card exactly acts as one of the Sound Blaster series cards and no further intervention by a 'driver' is necessary.
- The card starts off 'inert' and requires some initialisation. This is common with 1995-1997 PnP compatible cards whose IRQ and DMA settings are done in software rather than by jumpers. My Avance ALS100+ based card and CMI8330 cards require a start-up program to be run before they will work. This program talks to the card, tells it what IRQ and DMA to use, and from that point onwards the card acts as a clone card. No persistent program resides in memory to translate a game's Sound Blaster DSP commands into Avance commands, etc. If you've installed the 'driver' for a clone-like card, this most likely applies to you.
- If the card is not capable of directly acting as a clone card because it is exotic like a Gravis Ultrasound, or a very new (relatively speaking: post 1996) Sound Blaster / Ensoniq PCI card, then it cannot be simply initialised into acting as an SB clone card. These cards require a software shim layer to be loaded resident to intercept Sound Blaster DSP commands and translate them in real time to commands the card understands. For the GUS, this is SBOS. If the game you're playing natively supports GUS, then you don't need SBOS. For cards without FM chips/clone chips present, the shim layer may synthesize the audio in software in real-time, with mixed results.
2) Game support to -consume- the interface
Completely independently of the above, is the 'driver' that provides the game's ability to talk to a specific sound card. This could be more precisely called an audio library, but since it also has to talk to the Sound Blaster / Windows Sound System etc DSP processors, it's also a driver. In this respect, a DOS game is sort of like a mini-operating-system into itself.
This driver takes the form of a library of routines that abstract the base primitives of the sound card interface into a useful, consistent set of commands for game developer.
By itself, a Sound Blaster provides a single output stream of audio and FM capability. A Gravis Ultrasound or SB AWE provides a wavetable interface to multiple short looping streams of sound-card-RAM-resident samples (in addition to the SB digitised stream and FM, for the AWE). The PC speaker goes beep.
The game programmer doesn't want to think about this level of detail - they want to start music, play an explosion, etc. It would be the driver's job to abstract these details: begin/stop output, start/stop sound effects, mix them, alter volumes, etc.
Early games would have these drivers coded directly into the game in a sort of ad-hoc fashion - Halloween Harry can only support original Sound Blasters, and the support is hard-coded into the game. Rise of the Triad has its own huge sound library; since RoTT is open source, you can see all of the different initialisation and support routines on Github.
For late, mature MS-DOS games like Theme Hospital, a library like Miles or HMI is used. If you've seen a sound card set up screen with dozens of sound cards available, then they most likely use one of these libraries. I point this out since the different sound card drivers can be shown in a directory listing as .386
or .ovl
or .hmi
files. Epic MegaGames Jensen-library games like One Must Fall 2097 and Jazz Jackrabbit store their sound card drivers in MDRV---R.MUS
files.
The sound card drivers in 1) would be provided on an installation disk with your sound card, if required.
The sound card drivers in 2) would be provided with or part of the games themselves.