One of the new audio components in Vista is a new process named audiodg.exe.
If you look at it in taskmgr, the description shows "Windows Audio Device Graph Isolation", but that's not really particularly helpful when it comes to figuring out what it does.
The short answer is that audiodg.exe hosts the audio engine for Vista. All the DSP and other audio processing is done in audiodg.exe. There are two reason it runs outside of the windows audio service.
The first is that there's 3rd party code that gets loaded into audiodg.exe. Audio hardware vendors have the ability to install custom DSPs (called Audio Processing Objects or APOs) into the audio pipeline. For a number of reasons (reliability, serviceability, others) we're not allowed to load 3rd party code into svchost processes (svchost.exe is a generic host process for services that's used inside Windows). So we need to move all the code that interacts with these 3rd party APOs outside the audio service (that way if an APO crashes, it won't take out some other critical part of the system with it).
The second reason for using a separate process for the audio engine is DRM. The DRM system in Vista requires that the audio samples be processed in a protected process, and (for a number of technical reasons that are too obscure to go into) it's not possible for a svchost hosted service to run in a protected process.
So why audiodg?
As I mentioned in my post "Audio in Vista, The Big Picture", the route that audio samples take through the audio engine can be considered a directed graph. Internally, we refer to this graph as the "Audio Device Graph" (ok, strictly speaking we call the part to the left of the mixer as the local graph, and the part to the right of the mixer the device graph, but when we consider the big picture, we just call it the audio device graph).
So why AudioDG?
Originally we called the process DeviceGraph.Exe. For a number of reasons that are no longer relevant (they're related to the INF based installer technology that was used before Vista), we thought that we needed to limit our binary names to 8.3 (it's a long story - in reality we didn't, but we thought we did). So the nice long names we had chosen (AudioEngine.Dll, AudioKSEndpoint.Dll, and DeviceGraph.Exe) had to be truncated to 8.3.
I felt it was critically important that all the audio components had to have the word "Audio" in the beginning to make it clear that they had to do with audio functionality. Since we thought we were limited to 8.3 names, that meant we had 3 letters to play with in the name. For AudioEngine.Dll, it was relatively simple - it shortened to AUDIOENG.DLL. Similarly for AudioKSEndpoint.Dll, it shortened to AUDIOKSE.DLL.
But DeviceGraph was somewhat more complicated. I originally went with AudioADG.EXE (audio+ADG for Audio Device Graph), but people thought it was redundant (It expanded to audio audio device graph).
Eventually we settled on "AUDIODG.EXE".
So why the funky description? Well because it accurately reflects what audiodg is - it's a part of Windows, so you get "Windows", it hosts the "Audio Device Graph", and isolates it from the Windows Audio Service.
OK, so protected processes were created to implement DRM, at least according to a white paper I see on the Microsoft website. Reading it, it looks like they basically prevent the normal stuff people would do to processes, like injecting code into them, reading the process memory, debugging them, from other user-mode processes. One question - is there something in Vista that prevents you from creating a kernel-mode process to do this? The white paper basically said "don't do that - it would be bad".
I'm wondering if the DRM is really that toothless?
I don't want to go into DRM implementation, but how would you go about creating the kernel mode process?
As I understand it, there are mitigations against that sort of thing.
Now, of course, someone will have to ask why their foreign-language version of Vista has the English audio.dll version. Why not audioesp.dll, audiochn.dll, or audiotlh.dll? [grin]
My assumption was that you'd be able to create an unsigned kernel-mode driver and load it, at least on 32-bit versions. That's what this webpage seems to imply, anyways.
Don't get me wrong - I'm not one of those raving fanatics who froth at the mouth on DRM. Since I have no plans on stealing stuff, as long as it doesn't cause problems when I play the media, and doesn't cause me to have to re-buy it multiple times it simply won't bother me. But it just seemed to me that someone spent a ton of work to do this for zero benefit, unless you disable playing protected content in the presence of a single unsigned driver on the system (which will be about everyone for awhile).
I haven't installed Vista yet anywhere, so I haven't had a chance to explore this.
Well, at some point someone needed to debug these so-called protected processes... i wonder how that was done?
Any software which relies on the kernel preventing code injections is fundementally broken if you have administrator/physical access. Kernel protection just makes things harder, not imposible.
Gil-Ad, you can disable protecting audiodg.exe with a registry key (it's documented in the "how to write a sysfx" document). Of course protected content won't play, but...
"...they're related to the INF based installer technology that was used before Vista..."
Larry, is inf based installing not anymore blessed by MS for Vista?
Stefan: If you're building a component that is deployed as a part of the Windows, then no, INF based installing is not supported (and hasn't been since before Vista Beta1).
This ONLY applies for components that are a part of the Windows operating system, I can't speak for 3rd party code.
I have a question. Do you know of any issues with resource issues and this process? Whenever I hear my fan working I look and, lately, audiodg.exe is using between 14 and 20% of my dual core processor. There is no sound playing or any apps open that would use it like media players. Is it a sound driver issue? Using a Creative Audigy ZX2 OEM. I've been hearing rumblings on the net about other issues like game features, but I've seen reference to resource issues as well. Any help is appreciated. - Eric
Eric, it's possible some application is capturing from the microphone. Audiodg.exe CPU usage of 14% is very unexpected though - even when rendering a reasonable number of streams (1-5) it doesn't use that much CPU.
Do you have any special audio effects enabled? It's possible those are chewing your CPU time up.
Any reason why audiodg.exe would be using over 300 megs of RAM? http://www.chrismartin.info/blah/audio.jpg
audiodg.exe is using 1 of my cores (though the memory consumption is only about 20megs for my system). I don't know if this will help, but I'm using the Asrock Dual SATA2 board, with an X2 proc. The realtek details:
Driver Version: 126.96.36.19913
Audio Controller: ALi(5455)
Audio Codec: ALC850
I don't have any of Realtek's equalizer or sound environment stuff running, and disabling all of the input ports (mic, line-in) doesn't change anything. (I didn't know if voice recognition could be to blame). Anyone have any thoughts? Thanks.
An update, I noticed that the realtek control panel was a legacy component. I couldn't uninstall just that w/out losing the drivers as well, but I did disable the control panel via the registry. This seems to have completely eliminated the problem, at least for my machine. For those w/ similar problems, try this:
2. You can find most of your startup programs in 1 of 2 locations in the registry
3. Right-click Run, and choose export to a file somewhere so you can undo your changes,
4. Start deleting entries (focus on sound programs).
5. If there's a program you don't know about, check the path. Sometimes that will give you a hint. Generally you can also put the full file name (soundman.exe for example) into a google search, and bring up some sites that will tell you what the file does.
6. Reboot after the change, and see if it helped.
Or you could ue Windows Defender to manage your startup programs :)
I'm still trying to figure out what's up with the excessive CPU consumption in audiodg, my current guess is it's a driver problem but I'm not sure yet.
As for the memory consumption in audiodg, try disabling system effects (it's in the properties tab for your audio devices (both capture and render)) and see if it changes things. You'll probably have to restart the audio service (to free up the wasted memory).