in reply to
how to mute system volume under windows 7
Since IAudioEndpointVolume is COM, the first thing to look at is Win32::OLE, but it won't work. IAudioEndpointVolume is IUnknown only interface. Not an IDispatch. Win32::OLE doesn't support IUnknown or "non-automation" interfaces. It must be what is called an IDispatch interface or "dual interface". I got this from reading http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/cb3de43e-3abb-4428-b58a-dc3e5f29db30/vista-master-volume-control-with-c?forum=windowspro-audiodevelopment since I dont have any NT 6 machines that would have the typelib on them. I don't know of any, but it doesn't mean noone has ever done this, way to make a IDispatch wrapper over a IUnknown only interface. Most dual interfaces, ones that have IDispatch but also C/C++ methods after the IDispatch methods in the vtable, use http://msdn.microsoft.com/en-us/library/ms221366%28v=vs.85%29.aspx to call a C++ method from a "eval" style IDispatch Invoke. See an example used here http://www.codeproject.com/Articles/13862/COM-in-plain-C-Part-2#DISPATCH. I understand some of that article series but not all of it.
I suggest you find a command line tool to manipulate volume or programmatically press the "mute button", see http://http://www.ptfbpro.com/automate/how-to-mute-the-sound-in-windows-by-hotkey/ and use Win32::GuiTest to save your sanity.
If you want to call C/C++ methods from Perl, read further. You can obviously use a C++ compiler and make an XS Module. IDK C++ so I wont comment on that further. You can also make a C XS module that wraps the method calls. But it will be painful due there being less info online on plain C COM vs MSVC C++ COM. ALL OLE METHODS are stdcall calling convention, so on a machine code level, ALL COM objects are pure, plain, C code, if your C++ compiler can tart up the COM object into formal OOP, that is between you and your C++ compiler. Since all COM objects are pure C code, it is possible, but very difficult (Win32::OLE and Visual Basic are a breeze compared to what you will be doing), to use Win32::API to call the COM methods. I am nowadays a maintainer of Win32::API. Before I took over maintenance of Win32::API, I wrote this demo of calling C/C++ only COM methods using Win32::API use C++ COM objects without any compiler. The monkeypatching of LoadLibrary and GetProcAddress in the demo are now obsolete since Win32::API supports arbitrary function pointers that do not come from DLL export tables. See the POD of a v0.70 Win32::API or newer. undef for the dll name param triggers function pointer mode. Beyond supporting function pointers, and ReadMemory() sub. I didn't add any other support for C/C++ COM methods. Things like dynamically inspecting typelibs for the C prototypes of the methods or parsing C headers (generated from typelibs/idls and stored on disk as C headers) describing the Vtable struct of the COM object, and splitting up the Vtable struct into function pointers, and giving correct Perl level names to each function pointer, you need to figure out yourself. Also Win32::API doesn't know any COM specific data types like BSTRs. You will have to make pointers to them yourself.
I probably could write a separate Win32::API::COM module to automate much of the details of using Win32::API with C/C++ COM, but I suck at COM, and I suck at designing APIs. Remember the .NET VM can bind to non-IDispatch C++ COM objects at runtime and introspect them (and SEGV style exceptions when it encouters a non-dual IDispatch interface without any C/C++ methods after the IDispatch methods). Perl can do this too, given the right amount of brain power.
Assuming Win32::API::COM existed, you are them faced with figuring out how to enter the mountain of classes and how to navigate to the correct classes, since MS's documentation barely, or never explains how to get or construct any of the 1000s of pointless classes that make up typical MS apps. You are searching for a needle in a hay stack. Most classes refuse to construct from nothing and must be obtained from an method with a 5 word description in some other class where the description is the method name with spaces in it.