Salut voila ce que j'ai trouvé:
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.
En gros faut pas le virer,faut faire avec....
"iexplorer.exe" processus
