A few of my favorite Win7 Sound features – Capture Monitor (aka Listen to…)

The capture monitor is a feature that allows you to listen to a portable media player (or any other microphone input) through your PC speakers. 

 

First a bit of history.  Way back in the dark ages (Windows XP timeframe), audio solution manufacturers used to include an analog circuitry that connected the line in to the speaker jack on the PC.  They routed this through an analog volume control and exposed this through the audio device topology.  People used this functionality to connect their portable media players to their PCs.  While this feature was popular with customers, the cost of providing the circuitry was too much for some IHVs and they started removing this functionality from their products starting some time before Vista shipped.

Not surprisingly, customers complained about this and we decided to implement equivalent functionality in the audio subsystem in Windows.  Because we’re doing this in the audio subsystem instead of in hardware, it allows you to configure the capture to run between any two devices.

 

To configure the capture monitor, you go to the properties page for the input device and select the “Listen” tab:

Once you select the “Listen to this device” checkbox (and hit apply), the system will start capturing data from the input and rendering it to the output device.  I’ve been using it to listen to my media player for months :).

 

I’ve been really gratified to see that both Ed Bott and Lifehacker (who picked this up from Ed) have noticed this feature, it was a huge amount of fun to write.  It was also my first experience using TDD (or rather a variant of TDD – instead of writing the test first then the code, I wrote the code and the test for the code at the exact same time) - based on my experiences, I’m totally sold on it as a development paradigm.

Comments

• Anonymous
  August 04, 2009
  That, actually, is really a pretty cool feature as I currently experience the lack of it on my XP system :-(

• Anonymous
  August 04, 2009
  The comment has been removed

• Anonymous
  August 04, 2009
  Oops, another UI faux pas! :p~ http://blogs.msdn.com/oldnewthing/archive/2007/03/14/1878777.aspx [X] Do not prompt when this device is plugged in If I uncheck that, it becomes "don't, do not prompt when this device is plugged in" I know Raymond says that "[t]he only exception to the 'no negative checkboxes' rule is the 'don't show me this message again' checkbox" but this not really a case of that (since it's not actually ON the prompt message).

• Anonymous
  August 04, 2009
  Dean: You're right, in this case the UX is reflecting the state of the underlying property.

• Anonymous
  August 04, 2009
  Larry, you forgot to tell us what the flat buttons in that dialog do.  Those icons are flat buttons, right?  Or is the speaker only a flat button when it appears in the notification tray volume control popout?

• Anonymous
  August 04, 2009
  What's the delay like?  Could you use it to connect a video game system (where delay is much more important than a portable music player)?

• Anonymous
  August 05, 2009
  The comment has been removed

• Anonymous
  August 05, 2009
  Hi Larry, I'm curious about the kinds of tests you wrote when working on this feature. Did the tests check for output in the sound device? How did you simulate plugging in a media device? Or did you just simulate sound coming into the microphone and check to see if it was coming out of the speaker output?

• Anonymous
  August 05, 2009
  Scott: The device arrival and removal events were simulated by enabling and disabling the audio endpoint (which generates events which are functionally identical to device arrival and removal events (they're subtly different but the capture monitor doesn't care about the subtle differences)).  And yes the tests check for output on the sound device - they rely on the metering APIs to confirm that samples are being generate.  I also rely on internal state changes to confirm the state of the rendering engine.  And a bunch of the testing is manual - you plug something in and listen to the speakers. Interestingly enough, the capture monitor uses only publicly documented APIs.  The tests also use very few internal-only APIs (basically just the ones that simulate device arrival and removal).

• Anonymous
  August 30, 2009
  larry, is there a way to enable/disable monitor programaticly?

• Anonymous
  August 30, 2009
  mitch: No, sorry.

• Anonymous
  September 18, 2009
  The comment has been removed

• Anonymous
  September 18, 2009
  Brannon, since this is a Win7/Server 2008 R2 feature it won't work on Vista or Server 2008. It should work on Server 2008 R2 if you enable the audio stack though.

• Anonymous
  October 11, 2009
  Really useful feature. Thanks. Can I use this feature and recording from that particular input jack simultaneously??