How Windows 3.11 Routed Audio to Sound Cards

In Microsoft Windows 3.11, routing audio output from software to physical sound card hardware was handled through a modular, layered architecture anchored by the Windows Multimedia system (MMSYSTEM.DLL). Applications did not interact directly with sound cards; instead, they passed digital audio requests through high- or low-level Application Programming Interfaces (APIs). These requests moved through installable hardware drivers and virtualized device drivers (VxDs) that coordinated Direct Memory Access (DMA) and Interrupt Requests (IRQs) to feed raw Pulse Code Modulation (PCM) data into the sound card's Digital-to-Analog Converter (DAC).

The Application and API Layer

Audio playback began with an application issuing a request to output sound. Software achieved this by calling into Windows 3.11’s multimedia subsystem using one of two methods:

  • Media Control Interface (MCI): A high-level, command-based API used for controlling multimedia devices (such as playing .WAV or .MID files) using simple string commands like play waveaudio.
  • Low-Level Waveform Audio APIs: Functions such as waveOutOpen, waveOutPrepareHeader, and waveOutWrite. Applications using these calls directly handled audio memory buffers containing raw PCM data.

The Multimedia Subsystem (MMSYSTEM.DLL)

Calls to the audio APIs were directed to MMSYSTEM.DLL, the 16-bit multimedia subsystem introduced in Windows 3.0 with Multimedia Extensions and integrated into Windows 3.1 and 3.11. MMSYSTEM.DLL served as an abstraction layer between user applications and the underlying hardware drivers. It tracked active audio streams, managed buffer queues, and translated API calls into uniform driver commands.

Device Driver Layer (.DRV)

MMSYSTEM.DLL mapped generic audio functions to device-specific dynamic link libraries, typically ending in a .DRV extension (such as SNDBLST.DRV or SB16.DRV for Creative Sound Blaster cards). The system loaded these drivers based on the configurations saved in the [drivers] section of the SYSTEM.INI file (for example, wave=sb16.drv). The .DRV driver was responsible for translating standard Windows audio buffers into the specific byte formats and command protocols expected by the specific sound card model.

Hardware Arbitration and Virtual Device Drivers (VxD)

Because Windows 3.11 primarily operated in 386 Enhanced Mode, hardware resources like I/O ports, IRQs, and DMA channels were virtualized to allow simultaneous operation of Windows programs and MS-DOS sessions. Virtual Device Drivers (VxDs)—such as VSBD.386 (Virtual Sound Blaster Driver) or VADLIBD.386—intercepted low-level hardware interactions. The VxD ensured that Windows applications and DOS boxes did not attempt to configure the physical sound card at the same time, maintaining system stability and preventing resource collisions.

Direct Memory Access (DMA) and Interrupt Requests (IRQ)

Once the driver initialized playback, the CPU was largely bypassed for data delivery to minimize system overhead:

  1. Base I/O Ports: The driver communicated control commands to the sound card using standard I/O port addresses (commonly 0x220 for Sound Blaster devices) to set playback parameters such as the sample rate (e.g., 22.05 kHz or 44.1 kHz), bit depth (8-bit or 16-bit), and mono or stereo output.
  2. DMA Controller: The sound driver programmed the motherboard’s 8237 DMA controller, assigning it an 8-bit or 16-bit DMA channel (typically DMA 1 or DMA 5). The DMA controller transferred the PCM audio data directly from system RAM into the sound card’s onboard FIFO (First In, First Out) buffer.
  3. Interrupt Requests (IRQ): When the sound card finished processing a given block of audio from the DMA transfer, it signaled the CPU via a designated hardware interrupt line (typically IRQ 5 or IRQ 7). The driver’s interrupt service routine responded to this signal by informing MMSYSTEM.DLL that the buffer was depleted, triggering Windows to release that memory back to the application and load the next audio block into the DMA pipeline.

Digital-to-Analog Conversion (DAC)

At the physical hardware level, the sound card's Digital Signal Processor (DSP) or onboard audio controller fetched the incoming PCM samples from the FIFO buffer. These digital binary samples were routed to an onboard DAC. The DAC converted the discrete digital values into a continuous analog voltage waveform, which was then routed through an analog low-pass filter and amplifier to the 3.5mm speaker or headphone jack.