This morning, Dmitry asked what the heck was the audio service for anyway.
That’s actually a really good question.
For Windows XP, the most common use for the audiosrv service is that if the audiosrv service didn’t exist, applications that linked with winmm.dll would also get setupapi.dll in their address space. This is a bad thing, since setupapi is relatively large, and for 99% of the apps that use winmm.dll (usually to call PlaySound), they don’t need it until they actually start playing sounds (which is often never).
As a part of this, audiosrv monitors for plug and play notifications (again, so the app doesn’t have to) and allows the application to respond to plug and play changes without having to burn a thread (and a window pump) just to detect when the user plugs in their USB speakers. All that work’s done in audiosrv.
There’s a bunch of other stuff, related to global audio digital signal processing that audiosrv manages, and some stuff to manage user audio preferences, but offloading the PnP functionality is the “big one”. Before Windows XP, this functionality was actually a part of csrss.exe (the windows client/server runtime subsystem), but in Windows XP it was broken out into its own service.
For Longhorn, Audiosrv will be doing a lot more, but unfortunately, I can’t talk about that 🙁 Sorry.
I really do want to be able to talk about the stuff we’re doing, but unfortunately none of it’s been announced yet, and since none of its been announced yet…
Edit: Corrected title. Also added a little more about longhorn.