I am a Software Development Engineer in Test working for the Windows Sound team. You can contact me via email: mateer at microsoft dot com
Friend key: 28904932216450_59cd9d55374be03d8167d37c8ff4196b
There's a bug that got away from me in Windows 7's HD Audio class driver (hdaudio.sys.)
Before I explain the bug, a few caveats:
If you're using Vista, there's no problem. This only affects Windows 7.
If you use the third-party audio driver, there's no problem. This only affects the Microsoft HD Audio class driver (hdaudio.sys.)
If your recording devices (mic and line in) are independent (can capture from both at the same time) or muxed (can capture from one or the other but not from their sum) then you're fine; this only affects mixed capture (can capture from one, from the other, or from their sum, but not from both sides of the mix independently.)
If either of your recording devices doesn't support jack presence detection then you're fine; this only affects mixed capture where both sides of the mix support jack presence detection.
Here's the bug.
Here's a sample state diagram assuming a mixed Mic and Line In (click to view full-size:)
Install the third-party audio driver instead of the HD Audio class driver.
Use audio extension cables to fool the jack presence detection hardware into thinking something is always plugged in.
Regular expressions are a tool for matching generic text. XPath queries are a tool for matching chunks of XML. Both are search technologies.
When using search technologies it is occasionally quite useful to have a query that will never match anything - for SQL, this would be something like "SELECT 1 WHERE 1 = 0".
My candidates for minimal unsatisfiable regular expression:
/a\bc/\b is a zero-width assertion that matches a boundary at the beginning or end of a word - specifically, it is true between a word-ish character (\w) and a non-wordish character (\W). Since literal "a" and "c" are both wordish characters, this will never match.
Or, if you allow Perl extensions:
/(?!)/This is a negative lookahead for an empty string. Since the empty string always matches everywhere, this will never match.
My candidate for minimal unsatisfiable XPath query:
/parent::*This matches everything at or under the parent of the root element. Since, by definition, the root element has no parent, this will never match.