What is a Driver?

By, Amir Majidimehr

Hang around people building music servers and computer programmers and sooner or later you hear the term “driver.” What is a driver anyway? To learn that, we need to first look at how computer systems are put together.

The basic function of a computer is to accept input from devices, perform operation on that, and output the results to another device. Examples of input devices are keyboard and mouse. Examples of output are graphics and printers. There are also combination devices such as disk drives that can both read and write data. We call these I/O devices for short (input/output respectively).

There are literally thousands of I/O device types and manufacturers. Yet seemingly, they all seem to work and are compatible with your computer. Plug in a mouse and no matter who made it, your computer recognizes and allows your application to accept your commands from it. This is all made possible by the “device driver” or driver for short. It is the glue that sits between your hardware and the operating system, letting the two communicate using a standardized manner.

A driver is part of the operating system such as Windows and MacOS. While a single company may be the provider of the operating system as a whole, anyone can write a driver and with it, extend the functionality of the operating system to work with a new piece of hardware.

The operating system company defines a set of interfaces or services the driver writer must implement. Think of it as the ability to put different make and size tires on your car. The interfaces for the driver are like the bolts that attach the wheel to the car. They have to match or it won’t fit. If someone invents a new mouse, regardless of how it works, it must return the parameters (x/y position) precisely the way the operating system requires it. An incomplete driver will not work and one with extra functionality will have features which won’t be usable or seen by the user.

Even though a driver is often written by a third-party, as soon as it is invoked (“loaded”), it becomes part of the operating system from that point on and acts as one. As such, the driver inherits the same powers as the operating system including unfortunately, the ability to crash the whole system.
Usigned Driver Warning

Indeed one of the common causes of operating system crashes is drivers. For this reason companies like Microsoft provide “driver certification” meaning that that the driver has passed a set of quality tests. Once it has achieved such a milestone, the driver get gets a seal of approval without which, you get an ominous warning from Windows when you attempt to install said driver.

Driver makers sometimes don’t want to go through the work and time it takes to get drivers certified by Microsoft. While many of these drivers work regardless, be cautious. All else being equal, a signed and certified driver is of higher quality. Needless to say, all the drivers that ship “in box” (come with the operating system) are signed and certified.

Back to operating system interfaces for the driver, in some instances there are multiple revisions or styles for these. We call these “driver models.” Operating system companies evolve the interfaces to accommodate new functionality in the hardware and or make up for past mistakes for creating too limiting of an interface.

For example if you want to write an an MP3 decoder, you can choose from two different styles in Windows; one called Dshow (DirectShow) and the other, DMO (DirectX Media Object). Note that that the kind of functionality you get out of the operating system and application may depend on the right driver being available.

Such is the case with sound card/audio hardware driver models. Traditionally in Windows there has been a divergence between the model the operating system provides for general use of the operating system and for Professional use (e.g. for audio recording and editing applications). The standard interfaces provides for general use includes mixing of the audio samples from multiple applications all attempting to output (e.g. hearing an email notification while playing music) and other conveniences such as software volume control and “sample rate conversion” (conforming all audio sample rates to the same value). The Pro models dispense with all of this and instead, provide for low-delay (latency) interfaces that simply pass data back and forth to the hardware.

The Pro interfaces such as WASAPI (Windows Audio Session API) and ASIO (Audio Streaming Input/Output) have become favorites of consumers building high-performance music servers because their usage bypasses the audio stack above it in the operating system. What is the audio stack? It is the code in the operating system that provides the convenience features mentioned above. Reason for their usage is that the audio pipeline/stack manipulates the audio samples even if you are not asking it to do anything with them. Audio samples are converted to an internal representation and conversion back which requires minor adjustment of samples (called "dither").

If you are a purist and want to play the audio samples in your ripped music without any transformation, you may want to opt to use the Pro interface/driver of your audio hardware. Since that interface has no data manipulation, your audio samples are sent to your hardware as is.

While some devices come natively with Pro drivers, not all do. Sometimes you can get third-party software which transforms your existing driver into the new model for the purpose of playing music. Alas, that is half of your problem. Not all media players support multiple driver models (and hence the comment earlier about functionality differences at application level). For example, while J River Media Center media player supports ASIO, Microsoft Windows Media Player and Media Center do not. So if the latter are your favorite applications, then you are not able to use the alternate driver models.

Sidetracking a bit, writing device drivers is the first step in learning to become an operating system developer. You are exposed to some key concepts and rules of the operating system environment but are not asked to understand the whole world all at once. This is the way I started my journey some thirty years ago to become a "kernel" developer. My first professional job was to write drivers for the Unix operating system (predecessor to Linux) starting with reel-to-reel magnetic drives used for backups. These devices are long history but maybe you recall them from science fiction movies:

Reel to Reel

Anyway, I hope this simple introduction at least covers the basics of what a driver is and its impact on your audio/video experience.

Back to Articles