What’s in your audio card?

No, it's not a credit card (obscure reference to a current credit card campaign running here in the US).

One of the things that really surprised me when I joined this group is the complexity of an audio adapter.

I had figured that an audio adapter was similar to most of the devices I'd run into over the years.  Relatively simple - a small command set - a register for volume, others for bass, treble, etc, and a register hooked up to DMA for rendering and capturing.

Boy was I wrong.

It turns out that an audio adapter has a remarkably rich internal topology - essentially inside each audio adapter is a complex topology of controls and connections.

We need to start at the beginning.  In general each audio adapter exposes two "filters" - the "wave" filter and the "topology" filter.  The wave filter is used for rendering audio, the topology filter contains the controls through which the audio passes.  Within each filter are a series of "pins", if you look below, the pins are the little black boxes on the outside of the larger boxes.

Essentially the topology of the audio adapter describes a complex path from a source pin to a destination pin (which usually corresponds to an external audio jack on the adapter).

But the path that the audio samples take through the driver can be quite complex.

You can see a rough approximation of this topology if you dump the mixerline APIs - but the mixer APIs don't always reflect the full richness of the device's topology - for that, you need to use a lower level tool like KSStudio (a DDK tool written by a member of the audio team several years ago)/

For a really simple example of an audio topology, I've attached the topology from the AC97 adapter in my test machine below:

The pink blob on the left is the topology filter, the pink blob on the right is the wave filter.  There are four "pin factories" on the wave filter - 0 is the render filter, 1 is the capture filter, two is the data output and three is the data input (ignore the direction of the arrows, it doesn't reflect the actual data flow).  The topology filter has 10 different inputs, corresponding to wave out, cd audio, aux, etc - the left hand column is essentially the list of source lines on the mixer topology.  It's important to notice that the only one of these that can be used by a PC application is number 9 (the wave pin) - the other pins are connected to external hardware inputs (for instance the analog audio output for my CDROM drive is connected to pin 4).  The right hand column roughly corresponds to the jacks on the back of the audio adapter - the top one (#10) is the pc speakers, 11 is the microphone input and 12 is the line input.

If you follow the path from the wave filter control 0, data flows from the render pin to a DAC (control 0) then is passed in analog form to pin 9 of the topology filter, to the mixer (pin 18), then to the master volume (16) and master mute (17) before going to the speakers (10).

One of the things to note when looking at the line in and mic graphs is the last control in the graph (27 and 30).  Those are mux controls - essentially the mux control selects which of the "input" lines (mic, etc) receives the signal from the microphone. 

Another control to notice is controls 4 and 5 (connected to the mic source).  Those are AGC (Automatic Gain Correction) controls - they help ensure that the input microphone gain is set correctly.

Comments (8)

  1. Anonymous says:

    Who chose the pink color scheme? 🙂

    While supporting the real topology of the underlying hardware is neat, it can also make application code much more complicated. For instance, DirectShow video capture drivers vary wildly in the front-end filters routing analog data to the main capture filter. Trying to write generic code that can crawl the graph and figure out the correct routes for a given input takes a bit of work. I shudder looking at the graph above when I think of how many weird upstream configurations could be attached to the capture filter that might trip up a routine trying to select line-in. For instance, I know of one sound card that has a "What U Hear" input that basically connects the playback path to the capture path — meaning that there are two ways to route each input to wave capture.

    Flexibility is great, but sometimes you just want an enableLineInput() function too.

  2. Phaeron, the pink was what happened when I cut&pasted the image into paintbrush. I’m not sure where it came from. It wasn’t my first choice.

  3. Oh, and Phaeron, we know that this is an issue, and hopefully you’ll be happy in the relatively near future.

  4. Anonymous says:

    my 2 cents on the pink…

    A specified color can be used to indicate that it should be rendered transparent. The default tends to be pink. I’ve seen this in toolbar images for VB.

  5. Yes, I generally used Magenta (#FF0000) as a transparent color for 4-bit and 8-bit indexed images (for true-color I prefer using alpha channels). I do think mostly because I cannot imagine using that God-awful bright color for anything else.

    Early ATI All-In-Wonder cards used it (or a slight variation) for the TV-on-desktop overlay feature, although newer cards seem to use an off-black color, as to not jolt the user with flashes of magenta. (Note: It’s fun to play with this feature by pulling up an imagine editing program and "drawing" on your TV-input.)

  6. Anonymous says:

    Yesterday, I described the internal topology of an audio card.

    But there’s no Windows API to expose…

Skip to main content