Indirect Disabling of Functionality

As well as overt disabling of functionality, there's also covert disabling of functionality. For example PC voice communications rely on automatic echo cancellation (AEC) in order to work. Echo cancellation is used to prevent sound from a loudspeaker or headphones interfering with a microphone in the vicinity. This is rather tricky because the sound will be modified by the speaker and the surroundings that it's operating in, so it requires fairly sophisticated signal processing to remove, as well as a high-quality copy of the signal (if you get a degraded copy the signal, it becomes much harder to use it to cancel out the echo with it). Although it's not visible, echo cancellation is very widely used in applications like hands-free car phones, standard phones used in hands-free mode, and conference calling systems.

AEC in a PC requires feeding back a sample of the audio mix into the echo cancellation subsystem, but with Vista's content protection this isn't permitted any more because this might allow access to premium content. What is permitted is a highly-degraded form of feedback that might possibly still sort-of be enough for some sort of minimal echo cancellation purposes.

Apparently this was written by someone who's never sat at a vista machine nor seen the changes at the application level in the way Vista's mixer handles audio from different applications. Acoustic Echo Cancellation functionality works fine in Vista here. As well as being commonly used in "applications like hands-free car phones", it's also commonly used in VOIP systems, and these seem to be unaffected in Vista. How to implement AEC (and we admit that how AEC is implemented at the driver level is different in Vista) is well documented in the DirectShow9 SDK for Vista.

The requirement to disable audio and video output plays havoc with standard system operations, because the security policy used is a so-called "system high" policy: The overall sensitivity level is that of the most sensitive data present in the system. So the instant that any audio derived from premium content appears on your system, signal degradation and disabling of outputs will occur. What makes this particularly entertaining is the fact that the downgrading/disabling is dynamic, so if the premium-content signal is intermittent or varies (for example music that fades out), various outputs and output quality will fade in and out, or turn on and off, in sync. Normally this behaviour would be a trigger for reinstalling device drivers or even a warranty return of the affected hardware, but in this case it's just a signal that everything is functioning as intended.

"If premium content signal is intermittent." We're trying to imagine a scenario where a premium content signal would actually behave this way.  The assertion seems to imply that premium content would be disabling hardware. Premium content can deny a particular output type, but this doesn't disable hardware. In an admittedly bizarre scenario where you were playing simultaneous protected and non protected content, say for instance over an SP-DIF coaxial link, the protected content would be denied if it's content usage policy dicated it, and the non protected content would play. The handling of content streams is abstracted from the actual hardware interface, which is part of the reason why drivers for video and audio have had to be drastically reengineered for Vista. Still, the concept of hardware abstraction is hardly a new one, so we're left scratching our heads here. The implication seems to be that disabling an output stream to a particular interface type is actually disabling hardware. This is not the case.