Background: In Windows Vista and above, using an expanded Core Audio API (by Ray Molenkamp and Xavier Flix) to enforce volume levels by subscribing to the DefaultAudioEndpoint’s OnVolumeNotification and setting the volume when it changes.
Problem: Functionally successful, but as soon as a subscription to OnVolumeNotification is registered, the CPU tends to get pegged at 30-50% depending on the power of your CPU. After much digging with Process Explorer & Process Monitor it was revealed that explorer.exe and sometimes svchost.exe would become consumed by registry read calls. I am uncertain of which registry key. I don’t believe I am subscribing to this event in a harmful way as I manage subscription carefully — it’s only being fired once.
Logical process of enforcing volume
- Unsubscribe from endpoint OnVolumeNotification
- Set endpoint volume scalar property (effective immediately)
- Subscribe to endpoint OnVolumeNotification
The underlying win32 methods involved in the Core Audio API are RegisterControlChangeNotify and UnregisterControlChangeNotify. Is it possible the issue is caused by these or the implementation of the event subscription?
Rather than:
I modified my logic to essentially use logic in properties with backing fields to manage when to update. It isn’t perfect, but it’s pretty damn close and it doesn’t eat up any CPU and it allows for external input from a slider with full support for INPC.