In windows Vista & 7*, how would you enumerate the programs which are currently playing audio (or trying to, in the event master volume is muted)? Essentially, I need the data displayed in the Volume Mixer found in the notification area.
Master volume is pretty easy:
ISimpleAudioVolume::GetMasterVolume()
http://msdn.microsoft.com/en-us/library/ms679156(VS.85).aspx
But nothing about particular programs is forthcoming.
*Obviously the target is Vista, but I see no reason a solution wouldn't also work in 7.
Language is irrelevant, though C# would be appreciated.
Fortunately your answer is incorrect. Check out the IAudioSessionManager2 interface - the RegisterSessionNotification API is your friend.
Related
Scenario: a windows laptop with several audio devices (speakers, mic, headset,...) and several applications/drivers that can change volume (media players, headset, skype, softphone, keyboard,...). At some point the volume changes without user action and I need to find who or what is the source.
So I'm looking for any API or tool that would allow me to monitor changes to volume levels (those are easy to find) AND more importantly: identify the process doing the change.
I'm in need of help. The situation is the following:
We have a software that runs on Windows Mobile 5 and 6. It is deployed in around 15 cities on different devices (Motorola MC35, MC55, MC65, MC75, MC75A, ES400). It works perfectly fine everywhere except in one city. They have MC75A devices and every once in a while we get a helpdesk about our software disappearing from the device.
The most interesting part is when we log in to check the device, all we can see is a damaged/corrupted file system and the OS, which is set back to default.
We tried to reconstruct the problem here at our company, but we find it impossible. I'm wondering if anyone has ever bumped into this.
I'm gonna attach two images of the corrupted file system.
We use custom windows settings and AppCenter to protect the operating system from our customers. (They shouldn't be able to modify any settings on their own).
In general such corruption happens when the driver is interupted saving changes to the file system.
That can happen, for example, when a high priority thread consumes all cpu times.
It may also happen, when the device is hard reset, for example by taking the battery out during thed river is writing to the file system.
A low battery normally cannot result in that corruption:
a) as the device shuts down itslef with critcal battery power
and
b) the file system is in flash RAM (in contrast to Windows Mobile 2003 and before) and does not need battery power to hold data.
It is also possible that there is a bad behaving process doing these corruptions.
As you say you see this only in one city: What is the main difference with the devices there?
Are others also using the same device? Maybe the device series itslef or there firmware is faulty (contact symbol/motorola for new firmware or patches to the 'disk' driver)
Are the users in that area doing special things to the devices that others do not? For example remove the battery when they mean the device does not react?
Is the MC75A used in other areas and there it does not show the corruption?
You see, you have some more items to examine a rule for the corruption?
When a volume is attached to file system, on Windows,
the Window explorer detects the volume and refreshes automatically.
I wonder the technique.
How do an program(include device driver) get the notification?
-Of course, it doesn’t mean a polling. I want to get an event(or a message).
I would like to get the notification when a network volume(like SMB) is attached.
Thanks in advance.
You're going to have to do some research, but basically you just need to register with the Windows IO Manager so that when the device is connected, some part of your code is called. RegisterDeviceNotification() is probably a good place to get started. When the device is connected, the IO Manager will send you a message, so you should make sure you have a proper callback setup for the message.
It would not hurt to read up on Windows Devices Services from the Windows System API. Depending on what you are doing, you may or may not need a driver as the generic driver provided by Microsoft is often good enough. For drivers, check out the Windows Driver Kit, it contains an excellent collection of sample drivers, as well as Win32 code for interfacing with drivers and working with hardware.
Good luck!
I have been looking into the possibility of creating a soft copy(image/EMF file) of everything printed from Windows - for archival purposes. Does anyone know if it is possible to create a hooking DLL that can grab the printed data in such a general way?
A low tech way of solving it might be to install pdf printer driver as the default printer and remove all others and set it up to automatically write all the files to certain directory on the network and then write a tiny app on another computer to monitor that folder for changes and if any new pdfs appear just print them out to a real printer.
Edit: Otherwise there's apparently something called the Print Monitor API. Here's an article that describes using that from VC++ 6 and seems to be pretty much what you want (assuming it's still supported by the OS you use).
Having looked at this problem in more detail the best solution seems to handle it through Spooler notifications in the Win32.
Our software should play sounds (not just small noises, but voice etc.). I wonder what about the volume control. The Windows Vista style guide lines says to define an application specific volume control in the Windows mixer.
But what about Windows XP and below? I don't think there is a way to get our control into the Windows mixer. BUT you can implement your own volume control, but if you don't modify the audio data, it cannot go louder than system wide volume (which might be very low or even mute).
The question is: should an application use it's own volume control or trigger the Windows volume control?
The problem is, that basic user doesn't even know where to setup the volume in Windows.
Most audio rendering frameworks (you don't mention which one you use) allow the user to control the audio of the stream passed from the audio rendering framework to the system audio engine. For example, DirectSound has a method IDirectSoundBuffer that allows you to set the volume for that sound buffer.
Per-application volume control (whether it's exposed via the system mixer or not) is a dramatically better experience for customers than an application controlling the master volume. Many machines (most current laptops for example) don't provide hardware volume controls and depend on the user to set the master volume to a comfortable level (which is a highly user specific value). If your application manipulates the master volume you're overriding the user choice and they're likely to be upset.
Btw, to be clear: I have no issues with MusiGenesis' choices either. For the specialized example of his application, that choice makes sense. Another similar example to MusiGenesis' example is a MIDI rendering application. If the application sometimes renders through hardware MIDI (with no volume control) and sometimes through software MIDI (with a volume control) it may make sense not to expose the volume control to the user to avoid confusion.
In my application (a software synthesizer/music composition tool) I actually don't touch the system volume or even offer a volume control for my own application. All my audio output is normalized to about 95% of the max possible level, and from that point the user can control the output volume either with the Windows volume control or the volume control on their speakers.
In my opinion, this is how a Windows audio application like this should behave, because typically when a software synthesizer is used it's the only application producing audio output, and the user already has two other ways of controlling volume (the Windows control and the speaker knob).
In the case of an application like yours, which is meant to play sounds in an environment where other applications may be making noise also, I think your application should only offer a way of lowering its own volume, without affecting the system volume. Most Windows users already know where the system volume control is (lower right toolbox), so it's kind of superfluous to add this control to your own application as well.
Our application needs to output voice as well, and also have different volume settings relative to other applications that may be running at the same time. We have a volume control that the user can change from within the application.
As such, in Windows 2000/XP, we do modify the system volume when our application gains focus, and set it back to the previous setting when we lose focus or when then application shuts down. This does work well, and does not seem to interfere with the workings of other audio based applications running at the same time (such as speech recognition software which is very sensitive to recording volume for example).
This is exactly the same behaviour as Vista and Windows 7, except that they do the work of maintaining the individual volume levels for each application (and in this case we disable the previously mentioned code).