How the Windows 98 Volume Mixer Processed Audio

In Microsoft Windows 98, adjusting system sound levels through the system tray speaker icon relied on a tightly integrated pipeline connecting a lightweight user interface to the sound hardware. This article examines how the Volume Control utility (sndvol32.exe) captured user slider inputs, translated them into commands using the Windows Multimedia API (winmm.dll), routed those instructions through the driver architecture—spanning legacy Virtual Device Drivers (VxD) and the then-new Windows Driver Model (WDM)—and ultimately altered physical gain levels or digital signal registers on the sound card.

The System Tray Hook and Sndvol32

The yellow speaker icon residing in the Windows 98 notification area was managed by systray.exe. Clicking this icon triggered a lightweight instance of sndvol32.exe, displaying a single master volume slider and a mute checkbox. Double-clicking the icon launched the full Volume Control application, exposing multichannel faders for Master, Wave, MIDI, CD Audio, Line-In, and Microphone.

When a user moved a volume slider, the user interface processed the GUI event via standard Win32 trackbar control messages (WM_VSCROLL or WM_HSCROLL). The slider represented a normalized scale (typically an integer value ranging from 0 to 65,535), which mapped directly to hardware gain boundaries.

The WinMM Mixer Architecture

Windows 98 processed audio volume changes using the WinMM (Windows Multimedia) subsystem. sndvol32.exe did not interact directly with hardware registers; instead, it interfaced with winmm.dll using dedicated Mixer APIs:

  1. Topology Discovery: During initialization, the application used mixerOpen, mixerGetDevCaps, and mixerGetLineInfo to query the sound driver's topology. The driver returned available audio lines (source lines like Wave, and destination lines like Master Out).
  2. Control Binding: It queried specific controls using mixerGetLineControls, identifying components such as MIXERCONTROL_CONTROLTYPE_VOLUME and MIXERCONTROL_CONTROLTYPE_MUTE.
  3. Setting Levels: When the slider position changed, the application populated a MIXERCONTROLDETAILS_UNSIGNED structure with the new scalar value and called mixerSetControlDetails.

Driver Translation: VxD vs. WDM

Windows 98 sat at the transition point between two driver architectures, both of which handled these mixer calls differently:

  • Legacy VxD Audio Drivers: Traditional Windows 95-style VxD drivers received mixer requests directly from the WinMM subsystem. The driver's internal mixer module converted the logical 16-bit WinMM value into specific hardware register values tailored to the card's onboard DSP or external mixer chip (such as an ESS, OPTi, or Sound Blaster register set).
  • Windows Driver Model (WDM): Windows 98 introduced WDM audio, which brought Kernel Mixer (kmixer.sys). When WDM drivers were active, WinMM routed mixer requests through the WDM audio stack. kmixer.sys managed software-level digital attenuation for shared audio streams. If the driver supported hardware mixing via a miniport driver, requests bypassed software attenuation and were sent directly to the device interface.

Hardware Execution and the AC'97 Codec

At the physical layer, the driver applied the value dictated by mixerSetControlDetails to the audio card:

  • Digital Attenuation: For software-only streams (like pure Wave playback on budget cards), the driver or kmixer.sys mathematically attenuated the 16-bit PCM samples via bit-shifting and multiplication before sending the data to the digital-to-analog converter (DAC).
  • Analog Attenuation (AC'97 / Dedicated Codecs): Most Windows 98 hardware implemented the Intel AC'97 specification. In these setups, the driver wrote directly to standard AC'97 registers (such as register 0x02 for Master Volume or 0x18 for PCM Out Volume). These registers controlled internal analog resistor ladders, physically attenuating or amplifying the analog signal before it exited the 3.5mm line-out jack.