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).
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?
I'm in the process of writing a specification to convert one of our most complex applications into an application which runs as a screensaver.
Currently this application will read from the file system & registry (User, but will be converted to Local Machine) and spawn multiple child executables drawing media elements on screen using WMP SDK and other media display libraries for images and flash. Some native to the OS, some not.
It is written in VB6 and must continue to be for this conversion.
This application currently operates as an application in the interactive account space. Usually with an account logged in as an administrator, or other highly elevated account. This application must operate without been logged in as a Screensaver.
Resources on doing this for my research are scant.
I'm keen to know the opinions of the SO community. Are there any limitations when running applications as screen savers when not logged in, considering security limitations of operating EXE's in this context. Are EXEs running as screensavers prevented from spawning other child processes or limited in reading file or registry information.
Are there any graphics handling restrictions with direct show or direct draw? Can systen ODBC's still be used?
This applies to Windows XP & Windows 7.
Thank you for your time.
Thought I'd come back and close this off.
After some testing and discussions with Microsoft it turns out you cannot run complex applications as a screensaver when not logged in.
The session used at the windows log in screen has a limited desktop heap allocation by design. Attempting to use multiple resources or open many windows will not work as the heap will simply run out of memory.
Proven by testing and by MS's own word.
I have a desktop computer that is hooked up to 3 different monitors of which only two can be active at any one time. One is a primary monitor and is always active. I can manually switch between the other two: one a monitor, another an HDTV.
The switch is a mechanical switch which only handles VGA (and at that, only the RGB components are actually switched) so there is no feedback to the computer from the other devices, thus windows can not make any automatic adjustments to change resolutions and things like that.
I want to make a batch file that will automatically switch the screen configurations and resolutions (hard coding the proper resolutions of course since we can't detect the other devices anyways) so that they are correct for the displays.
Where is the best place to get started? Where can I find library of commands (or whatever they are called) to do something like this? Lastly, is there anything I should be careful about when attempting something like this?
Thanks in advance,
-Faken
Try reschangecon (yes, there is a console version!).
It is safe, because it won't let you set settings that are not supported (without the force flag).
http://www.12noon.com/displaychanger.htm (It is free for personal use)
I've used ResSwitch to do this on my friend's HTPC that periodically forgot what resolution to drive his TV at, you call it like this: resswitch.exe 1920 1080 32 60
http://www.naughter.com/qres.html
The risk is it doesn't ask you to confirm, so you better be sure your monitor can handle the resolution you're asking for.
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.