|
Answer» Surprised I havent deal with this issue sooner than now. But There is a system running Windows 7 64-bit that has different profiles on it. And it appears that the audio properties are SHARED between all users vs written and saved to profile. So the last person to adjust the audio level in Windows, is what all others now have for a volume level as well as muted or enabled.
Trying to figure out if there is a way to fix this. The problem being that one person will log off and have their volume setting set to the max and the next person to logon has the audio cranked when they had it muted prior and inherrit the audio settings of the last user. Unfortunately its not as easy as removing the set of speakers and saying enough is enough no more sound, they need it as part of their job.
So sharing this here in case anyone knows of a way. I am tempted to take a set of speakers and set the volume to 50% with the knob and pour super glue into the potentiometer so that the speakers will never go to 100% max volume ever again however there has to be a better way at the system level to deal with fixing this half ... method that microsoft used to share the audio settings among all users and should have had the audio level setting and enabled or muted written to user profile when a user logs off so that when they log back on their settings are theirs and not the last persons. From what I can find, the only Audio settings stored per-user are the per-application mixer settings. These are stored here:
Code: [Select]HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\LowRegistry\Audio\PolicyConfig\PropertyStore
They aren't really stored in a user-readable format, but they are stored as ratios of the Master volume (which is why changing the master volume adjusts other sliders in the volume Mixer, I expect).
The Master Volume is a property of the sound device itself, and thus a setting of the local system, not the user. I suspect the reason is to avoid a very similar scenario to what you've described- if it was part of the user profile in the user hive, I believe it would roam, which means that a user's volume would APPLY to other machines they log into, which could be problematic in many of the same ways you've described.
There is a command-line tool, nircmd which appears to provide the ability to adjust the system volume. It doesn't provide a way to retrieve the current volume, but you could use it in a login script to set the volume to 50% at log-on, from what I can tell, this would work:
Code: [Select]nircmd.exe setsysvolume 32768
If only we could set the system volume, it would be possible to work up a script, I expect.
This got me thinking that surely it is possible for a program to do this itself- after all, Nircmd seems to be able to retrieve it. I did a few searches on that and found a few code samples that used the Vista and Later Core Audio APIs to retrieve the current sound level, but I wasn't able to determine how to add the ability to set the volume level. My searches, however, did lead me to this project.
I decided the subject struck my fancy, so I created Volume Slapper, which attempts to be a basic command line tool for setting and getting the volume level. For convenience I also put the installer on my website using my new download setup.
Some caveats:
The main caveat is that I wasn't able to GET it to work with .NET 3.5. That matters since if I was able to do so, Windows 7 comes with .NET 3.5 so nothing would need installed. As it is it needs .NET 4.0, which appears to be a requirement of the Core Audio library. A minor issue, really.
Note also that installation is only a convenience thing. Really you can take the executable and the Vannatech dll and put them wherever as is and the program will work (as long as .NET 4 is installed).
My thought process is that being able to set or get the volume on the command line should make it possible to create logon and logoff scripts that will restore and save the current master volume, respectively. logoff could redirect the output of the VolumeSlapper get to a file stored in the users profile (%APPDATA%\volume.dat for example):
Code: [Select]VolumeSlapper get > %APPDATA%\volume.dat
and logon could do something like:
Code: [Select]if not exist %APPDATA%\volume.data goto ending
type %APPDATA%\volume.dat | set /p volumelevel=
VolumeSlapper set %volumelevel%
:ending
That's an example, no idea if it works as I'm not much of a batch person. (the path to VolumeSlapper would presumably need to be changed) As I recall you're a bit of a weirdo (heh) and seem to prefer having everything hacked into one executable, more or less. I found a few results for C++ as well that use the same APIs (which are part of the windows API itself) but it didn't strike my fancy that much that I was going to muck about with C++
Thanks BC with assistance with this. Going to try that out.
Quote That's an example, no idea if it works as I'm not much of a batch person. (the path to VolumeSlapper would presumably need to be changed) As I recall you're a bit of a weirdo (heh) and seem to prefer having everything hacked into one executable, more or less. I found a few results for C++ as well that use the same APIs (which are part of the windows API itself) but it didn't strike my fancy that much that I was going to muck about with C++
Grins yes I suppose the code examples I have shared have been those that could be ADDED to a Rube Goldberg museum if there was one or would send me to an asylum of twisted minded programmers by mixing and matching instructions into a single compiled EXE such as using system(); calls in C++ as well as I have also done with Perl which just runs as the .PL to call to other stuff outside of itself at the command shell vs having it all run from within as a means to avoid reinventing the wheel at times and bend other executable functions to my needs.
Best system created so far in such a way of twisted programming and hardware hacking/modding was making a system that monitored my prior employers network for main location and 5 SATELLITE locations and when there was a problem it would call me on my cell phone and play prerecorded audio files to me as to where the problem was at in my own voice of predefined error conditions that could occur. And it kept calling me over an over until I reset it so if I was outside of a cell reception area and then got 1 bar I would get the call and see the unique phone number that was only used by my system a private fax line .... This worked really well, and I was able to act so fast on issues that end users thought that the infrastructure was running so much better than it has in years, when it was but it wasnt without me having to fix stuff behind the scenes as quickly as it was detected so that end users wouldnt detect it.... however a better method may have been to just pass the error condition to an e-mail and have the exchange server pass it off to me by an e-mail alert, but a phone ringing I would be more prone to be notified by vs an e-mail to self so I went the unusual route. I could go into pages and pages as to how it was designed and how it functioned, but that would put some people to sleep.
|
