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.
That, actually, is really a pretty cool feature as I currently experience the lack of it on my XP system :-(
Well.. I had this on every soundcard I owned since the 90's. Unfortunately, the laptop now doesnt. Software solutions suck at this (e.g. try playing an instrument with this).
Is good to know that win7 has a workaround though..
Oops, another UI faux pas! :p~
[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).
Dean: You're right, in this case the UX is reflecting the state of the underlying property.
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?
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)?
Mark: The delay is something like 80ms. It's enough that if you're listening to a live source and the capture monitor at the same time, you hear a slight reverb effect - it's most noticable on spoken word. I could have tightened it down so that it was almost indetectable (6ms or so) but that would have prevented other components from using the devices (which was clearly a non goal).
Ben: Those icons are just images, not controls.
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?
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).
larry, is there a way to enable/disable monitor programaticly?
mitch: No, sorry.
Larry, does this work on Server 2008 (with the desktop experience/audio service enabled) ?
I would like to use this at work, but my dev workstation is Server. When I plug my PMP into my line-in/mic combo jack, the level meter indicates there is sound coming in, but I don't have a "Listen" tab (note: the jack seems to be acting as line-in, rather than a mic).
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.
Really useful feature. Thanks.
Can I use this feature and recording from
that particular input jack simultaneously??