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

  • Article

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:

Listen to... control panel page

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??