In a phone system we use VOIP. There is a really big jitter which causes a robotvoice-like effect on the first call everytime I refresh the webphone. This is a big problem because refreshing happens a lot. How can I annul this effect?
This is most probably a problem in the client software itself. Maybe it is choosing a too long buffer by default and then adjusts it based on first call statistics. Check if it has some maxjitter, maxaudiobufferlength or similar setting and adjust it after your needs (Or contact the developers if there is no such setting).
Related
My question is about the delay between calling the present method in DirectX9 and the update appearing on the screen.
On a Windows system, I have a window opened using DirectX9 and update it in a simple way (change the color of the entire window, then call the IDirect3DSwapChain9's present method). I call the swapchain's present method with the flag D3DPRESENT_DONOTWAIT during a vertical blank interval. There is only one buffer associated with the swapchain.
I also obtain an external measurement of when the CRT screen I use actually changes color through a photodiode connected to the center of the screen. I obtain this measurement with sub-millisecond accuracy and delay.
What I found was that the changes appear exactly in the third refresh after the call to present(). Thus, when I call present() at the end of the vertical blank, just before the screen refreshing, the change will appear on the screen exactly 2*screen_duration + 0.5*refresh_duration after the call to present().
My question is a general one:
in how far can I rely on this delay (changes appearing in the third refresh) being the same on different systems ...
... or does it vary with monitors (leaving aside the response times of LCD and LED monitors)
... or with graphics-cards
are there other factors influencing this delay
An additional question:
does anybody know a way of determining, within DirectX9, when a change appeared on the screen (without external measurements)
There's a lot of variables at play here, especially since DirectX 9 itself is legacy and is effectively emulated on modern versions of Windows.
You might want to read Accurately Profiling Direct3D API Calls (Direct3D 9), although that article doesn't directly address presentation.
On Windows Vista or later, once you call Present to flip the front and back buffers, it's passed off to the Desktop Windows Manager for composition and eventual display. There are a lot of factors at play here including GPU vendor, driver version, OS version, Windows settings, 3rd party driver 'value add' features, full-screen vs. windowed mode, etc.
In short: Your Mileage May Vary (YMMV) so don't expect your timings to generalize beyond your immediate setup.
If your application requires knowing exactly when present happens instead of just "best effort" as is more common, I recommend moving to DirectX9Ex, DirectX 11, or DirectX 12 and taking advantage of the DXGI frame statistics.
In case somebody stumbles upon this with a similar question: I found out the reason why my screen update appears exactly on the third refresh after calling present(). As it turns out, the Windows OS by default queues exactly 3 frames before presenting them, and so changes appear on the third refresh. As it stands, this can only be "fixed" by the application starting with Directx10 (and Directx9Ex); for Directx9 and earlier, one has to either use the graphics card driver or the Windows registry to reduce this queueing.
Space Issues in a filesystem on Linux
Lets call it FILESYSTEM1
Normally, space in FILESYSTEM1 is only about 40-50% used
and clients run some reports or run some queries and these reports produce massive files about 4-5GB in size and this instantly fills up FILESYSTEM1.
We have some cleanup scripts in place but they never catch this because it happens in a matter of minutes and the cleanup scripts usually clean data that is more than 5-7 days old.
Another set of scripts are also in place and these report when free space in a filesystem is less than a certain threshold
we thought of possible solutions to detect and act on this proactively.
Increase the FILESYSTEM1 file system to double its size.
set the threshold in the Alert Scripts for this filesystem to alert when 50% full.
This will hopefully give us enough time to catch this and act before the client reports issues due to FILESYSTEM1 being full.
Even though this solution works, does not seem to be the best way to deal with the situation.
Any suggestions / comments / solutions are welcome.
thanks
It sounds like what you've found is that simple threshold-based monitoring doesn't work well for the usage patterns you're dealing with. I'd suggest something that pairs high-frequency sampling (say, once a minute) with a monitoring tool that can do some kind of regression on your data to predict when space will run out.
In addition to knowing when you've already run out of space, you also need to know whether you're about to run out of space. Several tools can do this, or you can write your own. One existing tool is Zabbix, which has predictive trigger functions that can be used to alert when file system usage seems likely to cross a threshold within a certain period of time. This may be useful in reacting to rapid changes that, left unchecked, would fill the file system.
I have a touch screen device that is running on windows CE. after 30 second the screen goes off to save power and will come back on it you touch it.
The problem is that randomly when the screen goes off the device will not come back on simply by touching the screen. I have a done a bunch of tests and there is no noticeable pattern to when this happens.
It appears to be performing the same action as when you press the suspend button from the main menu.
I have done some research and found there are 4 power saving settings in the registry and I think I need to disable one to stop the device from "suspending". I never want the device to turn off except for the screen going off, it is always connected to power.
Does anyone know how I can do this or why it is randomly suspending ?
And the entire device is in Chinese So really precise instructions would be appreciated. My application runs on top of the CE.
I know you're after precise instructions, but it's not that simple. The device OEM defined and implemented the power management system for the device, Microsoft only provided the structure for it. The OEM could have implemented power management in any way they sought fit,, and in fact they could have completely ignore the Microsoft-provided framework (wouldn't be the first time an OEM did that). Really you need to get a hold of the OEM and ask them how to prevent the behavior you're seeing or to get something different.
Barring that, you could always play around with the registry entries, but again, there's no guarantee any of them will work. You might look at adjusting power state or the activity timer registry entries.
Playing with the power manager control panel applet might also help (it's probably labelled 电源管理)
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\Timeouts]
"BattSuspend"=dword:0
I've got a WinCE device powered over ethernet (PoE) and I want to prevent File-System corruption following a potential power loss, e.g. user pulling the plug.
As a side note, I'm already using TexFAT which is supposed to prevent FS corruptions. While the later certainly does help reducing FS corruptions (over using plain old FAT), it doesn't entirely prevent some to still occur from time to time... So, I'm considering using a small rechargeable backup battery that would give WinCE enough time to cleanly shut down. Now, I can't find any info on the shutdown process: how to trigger it, how long it takes, and so on... MSDN is pretty quiet on this topic. Any idea?
The powerdown sequence is totally platform dependent.
The following answer is relevant to Windows CE 6. It may be different for previous versions of CE.
If you include the power manager component in your system, then the sequence is plus minus this:
Send go to D4 to all the drivers that are powermanageable and that reported they support this state. Otherwise, the driver gets the lowest powerstate it supports.
XXX_PowerDown is called, but it is not commonly used in Windows CE 6.
In between the registry is flushed in case you have a Hive Based registry and you enabled the registry flush thread. You should disable this in a fragile system such as yours
OEMPowerOff
device down
Just found a post by Bruce Eitman on what happens when Suspending. He puts it better than I do.
The Suspend sequence is what you'd do before loosing power.
I want to be able to intercept (and do arbitrary processing on) auto-repeating key presses on Windows. I'd like to know how keyboard auto-repeat is implemented so that I know what options I have. i.e. can I intercept at the:
application,
device driver and/or
hardware level
?
Update: It looks like auto-repeat is (poorly?) generated at the hardware level and then overridden by device drivers (see here).
To modify or filter behavior, you can intercept keys using a hook:
SetWindowsHookEx using WH_KEYBOARD
The hook procedure receives, among others, the repeat count (due to holding down the key)
Note that the low level keyboard hook (WH_KEYBOARD_LL) does not receive the repeat count.
If all your windows are created in the same trhead, you can use a thread-specific hook, and avoid moving the hook procedure to a DLL.
I dimly remember that repeat counts are generated by the keyboard itself and the LL hook sends repeated keydown events - I may be mistaken, though. Under DOS, the key repeat rate and time that was set in BIOS or through a BIOS call did return to default values when a DIN or PS/2 keyboard was unplugged and replugged. I am not sure WHY you need to know exactly.
I suggest that you might want to edit your question... your actual question is "How to suppress auto-repeat on Windows in ${yourLangauge}"...
To which my response is, I haven't got a clue, I've only ever done it in assembler (MASM 80286)... and even then I found a solution on a BBS (does anyone remember them) and just used it. From memory, the intercept has to be done at the device-driver level.
The implementation of autorepeat ($100 says it's assembler) problably won't shed any light on supressing it... that and Microsoft plays those cards very close to it's chest.
Cheers. Keith.
EDIT: I've just thought... techniques may now differ between versions of windows and the plethora of various devices... Oh goodie!
Sounds likes this is "Not programming related", however.
Go to "Accessibility Options" in control panel.
Select "Settings" under "Filter Keys" group, in here, you can switch off repeating keys for that user on that machine.
Hope this is what your looking for.
P.S. Above instructions given for Windows XP.