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.
Related
I'm writing a utility that addresses a Bluetooth status indicator light when my webcam is in use so that I'm not disturbed during meetings while working from home. Presently, I'm parsing the output of lsof to see which processes have a file descriptor open to VDC, but this approach is fraught for a number of reasons:
Not all processes with a FD to VDC are actually using the webcam (ex: avconfere, the Facetime daemon, and Chrome, which always holds a FD if it is open).
Most processes spin up a second process when the webcam is actually in use, and that child process doesn't always share a name in common with its parent, meaning I have to maintain a mapping to know which program is using the webcam.
Some applications (like Zoom) don't release the webcam FD when the webcam stops being used (only when Zoom is killed completely).
Is there any other/better interface for accurately determining which processes are using the webcam? Applications like Oversight lead me to believe that there should be a better method of doing this.
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?
Got a customer request but no idea can it be done. So need your opinions on this. This might be a utterly stupid thing to ask but yet need some facts so can work out best solution.
Scenario,
My Customer is an OEM Manufacturer. They make an automated system with a embedded touch screen (Windows XPe) this system got a button panel with some LED indicators (apart from keyboard) and 7 USB Ports. These button panels and USB ports are checked before sending to QC process. Currently a USB thumb drive with standalone executable with all indicators and controls flags is inserted to one of the USBs and then will run the exe. This exe capture user inputs from button panel and indicate which button is pressed so that it can be verify as working. And from program user can set LED indicators to different states (flashing, steady and off) so they can be verified as well. Once this is done then USB thumb drive will be inserted to each port and will verify it recognise. But after each verify step it needs to safely remove the drive from task bar. Once each test is finish user required to fill up the sheet with all pass and fail states for the entire button panel, indicators and USB ports. This is a quite length process when its come to mass production.
Apart from this embedded system all other components which suppose to connect to one of above embedded systems are tested via a program which I make and records all test outputs as they are tested. This program installed and components are connected to a testing embedded system.
Requirement,
What customer asks, can my program test completed embedded system with our host system (testing embedded system, may be via USB to USB) Its more like Testing a PC from another PC. Any ideas ?
Additional Info.
Apart from USBs there is one Network Port.
Thanks for looking, Feel Free to ask any questions. Any opinion is appreciated.
I'm not an expert on this topic, but it seems like this would be problematic because USB is an assymetrical protocol. There are hosts and there are devices. Hosts make the requests, and devices fulfill the requests. The problem is that PCs are USB hosts, not USB devices, so you would have two hosts trying to get the guy on the other side to do what he wants. Testing with a USB thumb drive worked because the thumb drive is a device.
It sounds like the unit to be tested doesn't have an ethernet port, which is a shame, because that would be the easiest way to go. If it has a serial port you could do it that way, but that is both slow and a hassle.
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).
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.